Use ~/.gem/$ruby/X.Y as the GEM_HOME

[postmodern]

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?

[postmodern]

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

[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

[postmodern]

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

[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.

[postmodern]

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

[ilikepi]

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.

[postmodern]

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).

[felixbuenemann]

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.

[felixbuenemann]

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

[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.

[postmodern]

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.

[felixbuenemann]

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.

[postmodern]

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.