chruby Use ~/.gem/$ruby/X.Y as the GEM

Now that Ruby has moved to Semantic Versioning it means each new release will have a unique X.Y.Z version. Since GEM_HOME is defined as ~/.gem/$ruby/X.Y.Z, this means each new release will have an empty gem dir, forcing users to re-install all gems.

Would it be safe to define GEM_HOME as ~/.gem/$ruby/X.Y, ensuring that gems are shared between patch releases?

Dec 28 '13 02:12 postmodern

There could be problems with gems that used internal C functions that were added in specific 1.9.x versions.

Dec 28 '13 02:12 postmodern

However, RubyGems 2.2.0 how keeps built C extensions in a separate extensions/ directory:

extensions/
`-- x86_64-linux
    `-- 2.1.0-static
         `-- bond-0.4.3
            |-- gem.build_complete
            `-- gem_make.out

Dec 28 '13 02:12 postmodern

The change might be as simple as export GEM_HOME="$HOME/.gem/$RUBY_ENGINE/${RUBY_VERSION%.*}".

Dec 28 '13 03:12 postmodern

Another blocker is that rubygems has generated fully qualified #! for it's binstubs, instead of the usual #!/usr/bin/env ruby. This makes it difficult to share rubygems between multiple Rubies.

Jan 03 '14 02:01 postmodern

Unfortunately there is no GEMOPT env variable we could set to enable the --env-shebang option by default.

Jan 03 '14 02:01 postmodern

We just ran into the fully qualified shebang issue ourselves when a coworker updated his version of ruby-2.0.0 and deleted the older version. Maybe it makes sense to just suggest in the README to include "--env-shebang" in the install/update parameters of gemrc?

As for removing one identifier level from ~/.gem/${ruby}/X.Y.Z, it seems slightly premature, given that 1.9 has not yet reached EOL and is distributed with Rubygems 1.8.

Feb 24 '14 23:02 ilikepi

Probably a good idea to document --env-shebang and gem pristin. Long-term, I wish #!/usr/bin/env ruby would be the default, and #!/path/to/ruby would only be used when ruby has a custom suffix (ex: ruby1.8).

Feb 25 '14 01:02 postmodern

I think it would make sense to use the ruby C API version for the directories, which would be 1.8 for ruby 1.8.x, 1.9.1 for ruby 1.9.1+, 2.0.0 for 2.0.x and 2.1.0 for 2.1.x. All gems compiled against the same API version are supposed to be binary compatible.

The c api version can be seen by looking at usr/include/ruby/version.h and the macros RUBY_API_VERSION_MAJOR, RUBY_API_VERSION_MINOR and RUBY_API_VERSION_TEENY, but I don't know how to get it with ruby code. This also doesn't really work for implementations without C api, like jruby.

May 14 '14 22:05 felixbuenemann

This is probably interesting to the discussion: Introducing a semantic versioning scheme and branching policy

May 14 '14 22:05 felixbuenemann

The following code returns the C API version:

require 'rbconfig'
puts RbConfig::CONFIG["ruby_version"]

On jruby this returns "1.9" while RUBY_VERSION returns "2.0.0", which might be because C-Extension support was removed in newer versions.

May 14 '14 22:05 felixbuenemann

Unfortunately using the API version would mean no gem separation between different versions. Also keep in mind that rubygems now generates an absolute #!/path/to/ruby for gem executables.

May 14 '14 22:05 postmodern

Isn't no gem separation between minor versions the point of the discussion? If upgrading rubies gem pristine --all --only-executables should do the trick. If sharing between rubyies with same API version is desired, then I guess --env-shebang in gemrc would do the trick.

May 14 '14 22:05 felixbuenemann

Ah it appears ruby-core is bumping the API version on each minor release, instead of having one API version for all 2.x.y releases. This might work after all.

I still wish there was an ENV variable we could set to enable --env-shebang by default.

May 14 '14 22:05 postmodern

Yes, that would be nice. For now I'm using this patch with 0.3.8:

--- chruby/0.3.8/share/chruby/chruby.sh 2014-05-15 00:48:18.000000000 +0200
+++ chruby/0.3.8/share/chruby/chruby.sh 2014-05-15 00:39:08.000000000 +0200
@@ -44,14 +44,16 @@

    eval "$("$RUBY_ROOT/bin/ruby" - <<EOF
 begin; require 'rubygems'; rescue LoadError; end
+begin; require 'rbconfig'; rescue LoadError; end
 puts "export RUBY_ENGINE=#{defined?(RUBY_ENGINE) ? RUBY_ENGINE : 'ruby'};"
 puts "export RUBY_VERSION=#{RUBY_VERSION};"
+puts "export RUBY_API_VERSION=#{RbConfig::CONFIG["ruby_version"] rescue RUBY_VERSION}"
 puts "export GEM_ROOT=#{Gem.default_dir.inspect};" if defined?(Gem)
 EOF
 )"

    if (( $UID != 0 )); then
-       export GEM_HOME="$HOME/.gem/$RUBY_ENGINE/$RUBY_VERSION"
+       export GEM_HOME="$HOME/.gem/$RUBY_ENGINE/$RUBY_API_VERSION"
        export GEM_PATH="$GEM_HOME${GEM_ROOT:+:$GEM_ROOT}${GEM_PATH:+:$GEM_PATH}"
        export PATH="$GEM_HOME/bin${GEM_ROOT:+:$GEM_ROOT/bin}:$PATH"
    fi

May 14 '14 22:05 felixbuenemann

Actually you could use Gem.ruby_api_version.

May 14 '14 22:05 postmodern

Actually Gem.ruby_api_version was added sometime in 2.x.

May 14 '14 23:05 postmodern

One problem with using API version is lack of separation between 1.9.1, 1.9.2, 1.9.3.

May 14 '14 23:05 postmodern

We could wait until 1.9.x is EoLed and then switch to using the API version.

May 14 '14 23:05 postmodern

Ah, that's nicer.

I grepped through the rubygems source, and there seems to be an environment variable GEMRC that can point to additional gem config files, so it would be possible to inject an environment specific gemrc.

Apparently you can do something like: GEMRC=/path/to/nother/gemrc:$TMP/extra/gemrc

It should be possible to share gems between 1.9.1, 1.9.2 and 1.9.3 as they all have the same C api version.