On 22/06/17 06:27, Ben Woodcroft wrote:
> On 21/06/17 23:12, Ludovic Courtès wrote:
>> Ben Woodcroft <b.woodcroft@uq.edu.au> 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.

Thanks,

Chris