Rename share/chruby/dev.sh to share/chruby/testing.sh (or other)

[postmodern]

@k0kubun @eregon do you have any objections to renaming dev.sh to testing.sh. I feel like dev.sh is a little too vague of a name. Other ideas include minimal.sh or no_gems.sh. I can rename it now before releasing 0.4.0, or hold off on renaming until 1.0.0.

[k0kubun]

I have no problem with it 👍

[eregon]

Thank you for asking.
I think testing.sh is rather vague too, and in fact that setting is for sure not limited to testing but useful for many other situations. If the default gem home is writable, it's actually the most robust setting to avoid mixing gems, and it also works fine when e.g. running /path/to/other/ruby/bin/ruby which is very convenient for benchmarking, trying different Rubies, being able to use multiple Rubies from a script without needing to know which Ruby switcher is used, etc.

minimal.sh seems better although since chruby is already minimal it's kind of "twice" minimal. It seems fine, but it's not really telling what it does.
no_gems.sh sounds like no RubyGems, which is not what it does.

I would suggest no_gem_vars.sh/no_gem_env.sh, that seems clear and IMO avoids confusion the best.

(BTW my original branch doing something similar but always is named do-no-set-gem-home)

[eregon]

For 1.0 (or earlier if it were to me) I would suggest that to be the default behavior and then have a set_gem_vars.sh/set_gem_home.sh/set_gem_env.sh file to opt-in to set GEM_HOME (and maybe GEM_PATH too).

[postmodern]

@eregon as for the default behavior in 1.0.0, how would it handle rubies installed in /opt/rubies (or elsewhere) where the ruby's gem installation directory is not writable by the user? Remember that /opt/rubies is the standard and registered /opt directory for additional rubies (there isn't really a standard for installing additional software into your home directory), is mentioned in the README, and I even use it, so it will have to also be supported by default and chruby would still need to ensure gem separation between other rubies (even with the same RUBY_VERSION but different installation directories).

Letting rubygems fallback to a --user-install gem-home does not ensure 100% gem separation between rubies. Also, rubygems still generates executable files with absolute #!/path/to/the/ruby which could lead to confusion if multiple rubies share a gem home. Having bifurcating logic to test whether the ruby's gem installation directory is writable or falling back to setting an explicit GEM_HOME is the next best option, but then the location of the gem home becomes dependent on where the ruby was installed, which could lead to confusion or make it difficult to write other utilities for managing/migrating chruby's ~/.gem/rubies/ directories.

My thought is that if the user does not want GEM_HOME set, that means the user has intentionally decided to install all rubies into ~/.rubies/ such that their gem directories are writable. This is an intentional choice on the part of the user, thus more suited as an opt-in configuration file that the user can intentionally enable, as opposed to a default configuration which is forced upon all users (even casual or novice users).

[postmodern]

I would suggest no_gem_vars.sh/no_gem_env.sh, that seems clear and IMO avoids confusion the best.

@eregon I like no_gem_env.sh, or no_gem_home.sh, or even no_user_gem.sh.

[eregon]

@eregon I like no_gem_env.sh, or no_gem_home.sh, or even no_user_gem.sh.

no_gem_home.sh sounds not ideal since there is still a gem home, just it's the default gem home.
That gives me another idea: default_gem_home.sh since it's effectively "use the default gem home as decided by RubyGems". And there is no no_ which sounds like it removes something when instead it just doesn't override/set GEM_*.

I prefer default_gem_home.sh, and then second no_gem_env.sh.

[eregon]

Re /opt and non-writable, I think one way would be to do the same as RubyGems, i.e., use the --user-install directory if the default gem home is not writable. And because chruby needs to deal with older RubyGems which doesn't have that, it would need to set GEM_HOME for that case.
Then it's like chruby "backporting" a usability fix from RubyGems, that seems quite nice and robust to me.

It would be nice to then call out to RubyGems to tell us the "user install dir" so then it's RubyGems' responsibility to separate gems as good as it can. But that has the problem below, though.

Letting rubygems fallback to a --user-install gem-home does not ensure 100% gem separation between rubies.

What do you mean specifically? Is there something else besides the executable files with absolute #!/path/to/the/ruby?
That situation is indeed unfortunate but also only affects CRuby, I think it should be fixed in either CRuby (change ABI per patch version since effectively sharing gems between 3.1.2 and 3.1.3 doesn't work in practice) or in RubyGems (default to --env-shebang).
Maybe setting --env-shebang in ~/.gemrc is the easiest workaround until it's fixed?

Using RUBY_ENGINE_VERSION instead of RbConfig::CONFIG['ruby_version'] (the ABI version) is a way to avoid that problem on CRuby. On non-CRuby they are the same (EDIT: not necessarily, but RUBY_ENGINE_VERSION changes at least as often as the ABI version). That's what #410 did.
In fact I now think this is better than #419 because that doesn't deal correctly with -dev Rubies installed again in the same directory (e.g., ~/.rubies/myruby-dev).
It could also be more explicit and use RUBY_ENGINE_VERSION only on CRuby, the ABI version on the others.
The big advantage of this whole apporach is it would not change the gem home for CRuby, it would only change it for TruffleRuby (where it's already badly broken on latest chruby release so doesn't matter) and for JRuby (it's also broken, the JRuby ABI/extension API changes on potentially every commit since it's "every public Java method", although it fails more rarely, still worth it too IMO).