[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#27438] [PATCH] Specify native search path for all ruby packages
From: |
Christopher Baines |
Subject: |
[bug#27438] [PATCH] Specify native search path for all ruby packages |
Date: |
Thu, 22 Jun 2017 06:40:17 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 |
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.
Thanks,
Chris
signature.asc
Description: OpenPGP digital signature