GNU bug report logs - #27438
[PATCH] Specify native search path for all ruby packages

Previous Next

Full log

Message #38 received at 27438 <at> debbugs.gnu.org (full text, mbox):

From: Ben Woodcroft <b.woodcroft <at> uq.edu.au>
To: Christopher Baines <mail <at> cbaines.net>, Ludovic Courtès
 <ludo <at> gnu.org>
Cc: 27438 <at> debbugs.gnu.org
Subject: Re: [bug#27438] [PATCH] Specify native search path for all ruby
 packages
Date: Thu, 20 Jul 2017 09:39:13 +1000

Hi Chris,


On 17/07/17 03:37, Christopher Baines wrote:
> On Thu, 22 Jun 2017 06:40:17 +0100
> Christopher Baines <mail <at> cbaines.net> wrote:
>
>> On 22/06/17 06:27, Ben Woodcroft wrote:
>>> On 21/06/17 23:12, Ludovic Courtès wrote:
>>>> Ben Woodcroft <b.woodcroft <at> 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.
> [..]
>
> 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?
Thanks for working on this. A few thoughts:

What happens to the default gems that come bundled with ruby itself? I'm 
interpreting from your patch that these will not be available?

In general, except for some special circumstances, we don't support old 
versions of software. To fix the issue that you are encountering 
properly with nokogiri probably requires new package definitions using 
"package-with-ruby-2.3" or similar to be made, I suppose. Ludo did some 
nice work making this easier (see 
https://lists.gnu.org/archive/html/guix-patches/2017-04/msg00126.html), 
but I worry in general about the resources required to support older 
Ruby versions. WDYT?

The gem-home procedure in ruby-build-system will now return an incorrect 
path, I think.

Perhaps I'm slow, but what are the advantages of the "vendor_ruby" 
method over exporting multiple GEM_PATHs as Ludo and I suggested? 
Changing the directory seems like a heavier touch and so more likely to 
misbehave. WDYT?

Apologies if this comes across a little negative, I'm just trying to 
consider all the issues. Thanks again for your efforts on this.
ben

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.