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
Conversation
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.
One can already control where rbenv versions are located with |
It is not. Setting My patch introduces a secondary directory in which to look for Rubies, but installing Rubies would still go to |
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. |
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 |
@mislav What's your opinion on the above? |
That's a good point. 🤔 With that in mind, it might be a better approach to designate a new environment variable. However, since |
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:
I'm thinking about supplying packages that just drop a bunch of files in /usr/lib/rbenv/versions/[version]. |
Hi @mislav, have you been able to come to a conclusion? |
Hi @mislav, it's been a while, can I bother you to have a look at this again? |
@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. |
Thanks mislav. No core requirements changed, but I did receive a bunch of feature requests that may be worth taking into consideration.
|
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 |
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 :) |
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). 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. |
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 So perhaps it would be a good idea to just add another variable like |
@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 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! 🙇 |
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.