Store all chruby GEM_HOMEs within ~/.gem/chruby

[postmodern]

Now that chruby uses the ruby's install-dir name for the GEM_HOME, we should isolate all chruby GEM_HOME from rubygems' directory structure to prevent conflicts. This would also make cleaning-up/uninstalling chruby much easier.

[eregon]

On the 1.0.0 branch it's like ~/.gem/ruby-2.6.3 for ~/.rubies/ruby-2.6.3 (1 level under .gem). That's already distinct from RubyGems which defaults to ~/.gem/ruby/2.6.0 (2 levels under .gem). Being more explicitly separated with ~/.gem/chruby sounds good, I agree.

[kwstannard]

Alternative suggestion, stop changing GEM_HOME and GEM_PATH and allow gems to install to the default gemdir? Then you don't have to worry about gem cleanup as it is someone else's responsibility.

[postmodern]

@kwstannard only problem with that, which has been discussed in-depth, is when the ruby is installed outside of the user's home (such as in /opt/rubies/) and the user does not have write access to the ruby's gem root. You could work around that by configuring ~/.gemrc to always do --user-install, but rubygems' Gem.user_dir does not properly isolate the gem homes by default. You could chown/chgrp/chmod the ruby's gem root so users can write to it, but then you have to perform additional steps and introduce security issues where multiple users share a common gem dir and could insert malicious code or uninstall another user's gems. You could change chruby to only recognize ~/.rubies/, but that breaks compatibility for users who want or need rubies installed globally in /opt/rubies; there are benefits to having software installed outside of your home dir so that it is not-writable by default and globally accessible, but user-installed dependencies installed within your home dir or project dir. Thus chruby has to work around rubygems' rigid defaults by setting GEM_HOME; ideally rubygems would check if the ruby's gem root is writable or not and fallback to the user's gem home, and compartmentalize gems in ~/.gem/ so that they never intermingle between different ruby installs.

My other concern is having gems installed in potentially two different places based on whether the ruby's gem root is writable or not (which is something not immediately obvious to the user), which could lead to confusion when I'm having to debug a user's issue with chruby. This is why I still like the behavior of always installing gems into the user's home directory for non-root users (visually recognized by a $ shell prompt) and not-setting GEM_HOME for root users (visually recognized by a # prompt or when running under sudo); this is actually the default behavior of Fedora's rubygems package which they tweaked rubygems' defaults so it that does not require sudo just to install gems as a normal user.

[kwstannard]

Thank you for the enlightening response! I didn't know about some of that and am now going to use it.

You could work around that by configuring ~/.gemrc to always do --user-install, but rubygems' Gem.user_dir does not properly isolate the gem homes by default.

This hypothetically does seem preferable to the other options. Do you have thoughts on tpope's reasoning for https://github.com/tpope/rbenv-communal-gems? I have used it before no problem and am this week trying to fork chruby to accomplish the same thing. I can let you know in a few months how it goes on my end.

[eregon]

From a quick look there is a good reason why to no share gems (at least C extensions) between different versions, even if they claim to have the same ABI (they might not). I found https://github.com/tpope/rbenv-communal-gems/issues/13#issuecomment-699540871 on that bug tracker. Not to mention different flags, enable_shared vs not, etc. IMHO it's a doomed path and already proven to not work.

I completely agree not setting GEM_HOME is by far the best thing to do, at least when the Ruby prefix is writable (probably 99% for dev usages), and it is what rbenv does (https://eregon.me/blog/2021/06/04/review-of-ruby-installers-and-switchers.html#chruby has more details, including my fork of chruby which does not set GEM_HOME).

[kwstannard]

Thanks for pointing me to that issue! That is a shame.

Thanks for your blog post as well. I always recommend chruby to people, but there is a lot of inertia.