Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support system-wide Ruby installations #1155

Closed
wants to merge 2 commits into from

Conversation

FooBarWidget
Copy link
Contributor

Makes rbenv look for Ruby installations in both ~/.rbenv/versions as well as in RBENV_SYSTEM_VERSIONS_DIR, if set. This allows installing Ruby versions in a system-wide manner that's available to all users on the system.

Makes rbenv look for Ruby installations in both ~/.rbenv/versions
_as well as_ in `RBENV_SYSTEM_VERSIONS_DIR`, if set. This allows
installing Ruby versions in a system-wide manner that's available
to all users on the system.
@jasonkarns
Copy link
Member

One can already control where rbenv versions are located with RBENV_ROOT, is that not sufficient?

@FooBarWidget
Copy link
Contributor Author

FooBarWidget commented Mar 28, 2019

It is not. Setting RBENV_ROOT to a single directory would mean every user has to have write access to that directory in order to install Rubies. Setting RBENV_ROOT also means that you cannot configure a per-user ~/.rbenv/version -- all users would have to configure the same version.

My patch introduces a secondary directory in which to look for Rubies, but installing Rubies would still go to ~/.rbenv. ~/.rbenv/version would still remain in the same location, allowing each user to configure its own preferred Ruby version.

@mislav
Copy link
Member

mislav commented Mar 28, 2019

Hi @FooBarWidget thank you for your contribution!

The code looks solid. I was, however, thinking about how "RBENV_SYSTEM_VERSIONS_DIR" doesn't sit perfectly with me as it's an oddly specific name for something that's basically a secondary RBENV_ROOT.

How would you feel about this:

export RBENV_ROOT="$HOME/.rbenv:/usr/local/lib/rbenv"

Basically, RBENV_ROOT becomes a list of paths to search for installed Ruby versions, global version setting, and plugins.

@FooBarWidget
Copy link
Contributor Author

No objections to that approach in principle, but there is one complication: all plugins, including ruby-build/rbenv-install, will have to be updated to support this new RBENV_ROOT format. Are you okay with that?

@FooBarWidget
Copy link
Contributor Author

@mislav What's your opinion on the above?

@mislav
Copy link
Member

mislav commented Apr 1, 2019

all plugins, including ruby-build/rbenv-install, will have to be updated to support this new RBENV_ROOT format.

That's a good point. 🤔 With that in mind, it might be a better approach to designate a new environment variable.

However, since libexec/rbenv is the entrypoint for all rbenv commands (and plugin operations), and since that's also the point where RBENV_ROOT is filled if one doesn't exist yet, theoretically it could take an RBENV_ROOT that has colons in it and transform it to one that only has a single path entry. This might be too magic of a behavior in practice. Let me sit on this for a few days and get back to you.

@FooBarWidget
Copy link
Contributor Author

FooBarWidget commented Apr 4, 2019

Let me explain my use case a bit better. I am looking to distribute Ruby binaries in the form of Debian/RPM packages.

The problem with the current distributions' Ruby packages are:

  • They only supply a few Ruby versions, but the Ruby versions actually in use by people is much more diverse. I want to supply packages for many more Ruby versions.

  • They only supply the latest patchlevel version of a minor version, but people often lock down to a specific patchlevel version. I want to supply packages for all patchlevel versions too.

  • They don't allow easy switching between different Ruby versions. In Debian, they do it with binary suffixes, e.g. /usr/bin/ruby2.4 and /usr/bin/ruby2.5. But that's difficult to use an error prone, and not supported by a lot of tooling (e.g. scripts with #!/usr/bin/env ruby).

    It would be great if the Ruby binary is just called 'ruby', but OS support for this varies. The Debian alternatives system only supports a global setting, but the way people use Ruby shows that being able to have a different Ruby on a per-user or even per-app basis is important.

    The Ruby version switching problem is effectively solved by Ruby version managers such as rbenv, so I want to supply packages that integrates with rbenv.

I'm thinking about supplying packages that just drop a bunch of files in /usr/lib/rbenv/versions/[version].

@FooBarWidget
Copy link
Contributor Author

Hi @mislav, have you been able to come to a conclusion?

@FooBarWidget
Copy link
Contributor Author

Hi @mislav, it's been a while, can I bother you to have a look at this again?

@mislav
Copy link
Member

mislav commented Oct 23, 2019

@FooBarWidget Just dropping a note that I'm taking this into consideration yet again. Doing some code experimentation on my own end first. Please let me know if your requirements changed in the meantime; thank you for the patience.

@FooBarWidget
Copy link
Contributor Author

FooBarWidget commented Oct 25, 2019

Thanks mislav. No core requirements changed, but I did receive a bunch of feature requests that may be worth taking into consideration.

@EugenMayer
Copy link

EugenMayer commented Mar 16, 2021

This PR is open for about 2 years - you can surely consider the effort dead (not happy about it either)

Or to put it in a more drastic way, the entire project is clinicly dead:

https://github.com/rbenv/rbenv/graphs/contributors
https://github.com/rbenv/rbenv/graphs/commit-activity

@EugenMayer
Copy link

Well i think rbend and chruby (both very mildly maintained at all, see https://github.com/postmodern/chruby) are working and kept alive to do so most probably - but nothing else.

I think the popularity of ruby probably decreased in a familiar fashion as those project started to fall asleep. Maybe they are considered feature-complete, used them both for a long time now with some limitations, but the basics are working fine.

So I guess take it as it is or since it's OSS, fork it and merge all the PR's you like :)

@EugenMayer
Copy link

EugenMayer commented Mar 16, 2021

IMHO you are 4 years behind the pulse here, but please emphasize on IMHO.

I used JRuby 6 years ago (with a big rails app), replaced it with a spring boot app for 4 years now God I miss nothing about rails+jruby and will never ever touch it again.

I used ruby for devops for 8 years, since about 2-3 years replacing all the rakes and thors with golang. Why? Zero dependencies to run on every platform, fat standalone binary - no fat ENV needed to run at all. And simply put, by far the better language (strong typed in addition).
Wished I would have written https://github.com/EugenMayer/docker-sync using golang too.

Not sure how much room there is left for ruby or rails. The cli probably falls to golang (or python).

The backend falls to Java/PHP/Golang and the frontend falls to all the Vue/React/Angulars.

So I guess, it's more a niche today and it will only become smaller (assuming my projection).

I should stop here now since that is far off-topic for this lovely PR here, which I wished to have 2 years ago.

@konsolebox
Copy link

konsolebox commented Aug 9, 2022

I somehow understand why it's difficult to merge this implementation. Personally I think it would be better to have a more generic approach which allows multiple root locations that doesn't only allow different locations for versions but also for plugins and hooks as well.

The problem now is that plugins and user hooks expect RBENV_ROOT to not contain multiple paths separated by a colon. The currently implementation also allows overriding RBENV_ROOT and only assign ~/.rbenv if nothing is assigned to it.

So perhaps it would be a good idea to just add another variable like RBENV_SYSTEM_ROOT. This variable can have multiple paths separated by a colon set so location of system-installed versions is not opinionated. Personally I would prefer installing system-packager-installed versions to /usr/lib/rbenv/versions, and allow non-system-packager-installed or root-user-installed versions to /usr/local/lib/rbenv/versions.

@mislav
Copy link
Member

mislav commented Sep 26, 2022

@FooBarWidget Thank you for elaborating, spiking out the implementation, and for your patience. This changeset is more code that I am comfortable accepting into the codebase right now, as I'm trying to get rbenv to a point where it's stable with minimal maintenance and few to no feature changes. For that reason, I am going to close this right now and I hope that a solution for your use-case could be made externally to rbenv core.

For example, the system could install a global hook at /usr/lib/rbenv/hooks/rehash/system_rubies.bash. The hook could iterate over the list of system rubies and ensure that each one is symlinked into RBENV_ROOT/versions/* at rehash time. Then, as any individual user starts interacting with rbenv, they will automatically get access to all system rubies as well as the ability to install their own, user-scoped versions.

This solution is not ideal, as it oversteps the boundaries of a system administrating writing into the user's home directory, but I think it's still less intrusive and less risky than this code change.

Finally, rbenv already gets a bad rap for being slow, and adding more directories and loops to directory lookups in almost every core command is just going to make it slower. Mainly for that reason I'm trying to resist feature changes.

Thank you again for giving me lots to think about! 🙇

@mislav mislav closed this Sep 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants