On Thu, 22 Jun 2017 06:40:17 +0100
Christopher Baines <address@hidden> wrote:
On 22/06/17 06:27, Ben Woodcroft wrote:
On 21/06/17 23:12, Ludovic Courtès wrote:
Ben Woodcroft <address@hidden> skribis:
On 21/06/17 16:36, Christopher Baines wrote:
Without specifying this explicitly in each definition, the
GEM_PATH is inherited and the version is that of the inherited
package.
I'm not sure if this is by design, but the version of the gems
folder is embedded in the build of each rubygem e.g. 'ruby-hoe'
includes
/gnu/store/d867l5i2dqd5qnq4qlsrcwwb0x3443fl-ruby-hoe-3.16.0/lib/ruby/gems/2.4.0
Or should the search path spec include both lib/ruby/gems/2.2.0 and
lib/ruby/gems/2.4.0, in this order?
Exactly.
Chris, what is your experience? Did you propose the patch because
you ran into a particular issue?
Yep, I ran in to problems trying to use the guix ruby-2.3 package with
the guix bundler package, when I build bundler with ruby-2.3.
Ben's email got me thinking about how this works in Debian, and it
looks like Debian uses a different
location /usr/lib/ruby/vendor_ruby/ .
I think there might be benefits from doing similarly, but this needs a
bit of thought and testing, as I'm unsure how this might work,
especially in cases where libraries include native code that links
against ruby.
I've got a patch for the ruby-build-system to make a change roughly
like this, and I'll send that up soon. Relating this back to the
issue at hand, moving to a version independent directory would mean
that the GEM_PATH wouldn't be version specific.
[..]
So, putting the gems in a single location regardless of the version of
ruby they were built with means that a different version of ruby will
at least see them, however, it may still fail to load them.
I think this is an improvement, but I'm very uncertain about ruby. Does
anyone else have opinions on this?