1.0.0 release

[eregon]

@postmodern Could you make a 1.0.0 release including the important bug fix #419 and the much better/reliable way not needing to set GEM_HOME in the common case of installing Ruby in a user-writable dir of #431 ?

I'd like to recommend chruby in a blog post and review the various Ruby switchers (based on my experience contributing to all 3 of them), but I can't until both these PRs are merged and released, because I've seen both issues would confuse users needlessly and e.g. path/to/some/other/ruby -S gem install foo wouldn't work and cause problems.

The only alternative I see would be to recommend using https://github.com/eregon/chruby/tree/do-no-set-gem-home, but I'd obviously prefer to not need to recommend a fork, also given the significant amount of time I've spent to make those PRs and reach agreement.

[eregon]

If I can help with anything (e.g., fixing the GitHub Actions on macOS), please let me know.

[postmodern]

I am still working on a refactor in the 1.0.0 branch; possibly splitting chruby_use into smaller functions to allow for more configurability. A major version release is a serious milestone and should not be rushed.

[eregon]

Is there a reason actually those changes need to go in 1.0? Why not simply 0.5 or so? Semantic versioning says:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

And really I wouldn't consider them breaking changes anyway, the switching functionality would work just the same or better, and users might have to reinstall gems, which they already do when e.g. installing a new Ruby version, and makes some sense too when upgrading a version switcher.

Regarding 1.0.0, do you have any estimation, is it a couple months, a year, many years?

I would have already gone to 1.0.0 a long time ago with chruby (it's been stable for a long time already), but I guess you have a different view on versioning.

[postmodern]

Good point, we could add additional options or internal functions to a 0.5.0 release, so long as we did not break compatibility by removing features or suddenly changing default behavior.

I have no estimate on 1.0.0 nor 0.5.0, however I am taking off December and possibly January to work exclusively on Open Source projects.

I tend not to bump to 1.0.0 once I've outgrown 0.x and decide that its finally time to break backwards compatibility and redesign the API.

[postmodern]

I am kind of OK with path/to/other/ruby -S gem install foo installing into GEM_HOME, when GEM_HOME is set. The purpose of chruby is to allow a user to switch to another Ruby, by modifying the shell's environment. If they wanted to install a gem into another Ruby, they should switch to that Ruby first, via either chruby other_ruby or chruby_use /path/to/other/ruby, or even clear the shell env with chruby system. Once a user has switched to a Ruby, it is expected that all ruby related actions happen wrt that Ruby and not some other Ruby.

[eregon]

I am kind of OK with path/to/other/ruby -S gem install foo installing into GEM_HOME, when GEM_HOME is set.

In all cases I know, the user intention was never to install and compile a gem of Ruby 1.x into the gem home of Ruby 1.y. In fact that's always a mistake if the gem in question has some native extension.

I understand why that happens, but many Ruby users would not and be confused. The source of that issue is setting GEM_HOME when there is no need for it. I've seen this the hard way myself and for many TruffleRuby contributors and other Rubyists, to the point I'm starting to hesitate to recommend chruby until this is fixed, and I'd really like to fix this :) (rbenv has the overhead of shims which is non-negligible and is more complex, and RVM is obviously the most complex)

Regarding a release, https://github.com/postmodern/chruby/pull/419 seems a clear bug, which unfortunately requires to change the gem paths to fix it. It would be great to have a release with it. While we are changing gem paths, it seems best to integrate #431 as well so we don't change them twice. And I think #431 is not less compatible than #419, so in other words IMHO they fine in a 0.5 release.

[postmodern]

I also feel like a lot of these edgecases could be better handled by RubyGems, in how it honors GEM_HOME or possibly providing options for installing into GEM_ROOT. Otherwise, chruby would have to provide such functions and expect the user to use them instead of bypassing chruby and running /path/to/other/ruby -S gem install ... directly. Although, I doubt many other Ruby users besides yourself and myself actually run /path/to/other/ruby -S gem install ..., so we might be trying to optimize for a red-herring edge-case.

419 is already in 1.0.0. I decided to change the directory to ~/.gem/rubies/... to 1) avoid conflicting with other directories created by gem install --user-install and 2) make cleaning up gem installed under chruby as easy as rm -rf ~/.gem/rubies/. I would use ~/.gem/$RUBY/$RUBY_VERSION, except rubygems still generates bin files with absolute #!/path/to/ruby.

Like I said in #431, I am exploring adding additional options to avoid having bifurcated default behavior, where Behavior A happens when the GEM_ROOT is writable or Behavior B happens when it is not writable. Please refrain from trying to argue with me or coerce me into merging it. These types of changes require careful consideration.

Seeing as how this issue isn't related to a specific chruby bug or feature, I will close it.