[bug#27438] [PATCH] Specify native search path for all ruby packages

[Christopher Baines]

On Thu, 20 Jul 2017 09:39:13 +1000
Ben Woodcroft <address@hidden> wrote:

> Hi Chris,
> 
> 
> On 17/07/17 03:37, Christopher Baines wrote:
> > 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?  
> 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?

They seem to be:

→ guix environment --container --ad-hoc ruby -- irb
...
for 1 packages... done in 0.028 s 
irb(main):001:0> ENV
=> {"PS1"=>"address@hidden \\w [env]\\$ ", "TMPDIR"=>"/tmp",
"TEMPDIR"=>"/tmp", "TMP"=>"/tmp", "TEMP"=>"/tmp",
"HOME"=>"/home/chris",
"PATH"=>"/gnu/store/2dh34pi9yjq17qf1bw3dmgcdpri20fjs-profile/bin",
"GEM_PATH"=>"/gnu/store/2dh34pi9yjq17qf1bw3dmgcdpri20fjs-profile/lib/ruby/vendor_ruby",
"GUIX_ENVIRONMENT"=>"/gnu/store/2dh34pi9yjq17qf1bw3dmgcdpri20fjs-profile",
"LINES"=>"76", "COLUMNS"=>"190"}
irb(main):003:0> require 'rake'
=> true
irb(main):004:0> require 'minitest'
=> true


> 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?

I'm not aware of any particular problems if you are working with the
package definitions in Guile, as it should be possible to make them use
the single ruby version that you want.

With the guix environment command I posted:

  guix environment --pure --ad-hoc ruby-nokogiri address@hidden -- ruby -e
  "puts require 'nokogiri'"

It would be ideal if there was some way of telling guix environment to
rewrite the package definitions of all packages to use address@hidden in
place of whatever ruby they might be using.

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

Good spot. I'll have a look at that.

> 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?

I agree that it is heavier in some sense, but I like the simplicity of
getting rid of the version from the path.

The best documentation I've found for this is the NEWS of the release
where it was added [1]. While Guix blurs the lines between the "package
system" and the "user", using this vendor directory might come in
useful.

1: http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7/NEWS

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

No need to apologise, I too think its important to consider the
details of the support for ruby, which is not something I'm
particularly knowledgeable on.

pgpXANY0HcdXr.pgp
Description: OpenPGP digital signature