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

Previous Next

Full log

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

From: Christopher Baines <mail <at> cbaines.net>
To: Ben Woodcroft <b.woodcroft <at> uq.edu.au>, 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: Sun, 16 Jul 2017 18:37:05 +0100

[Message part 1 (text/plain, inline)]

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... I kind of forgot about this, sorry about that. But I'll send up
the patch shortly.

As an example of what this change means, here is a example of loading
ruby gems with different versions of ruby, with the current and
alternative situations.

I think arel doesn't use native extensions, whereas nokogiri does.
Also, ruby <at> 2.1 is used, as the search path for the guix package
reflects the version of ruby (whereas many others don't).

* Current

** With the version of ruby used to build the gem

→ guix environment --pure --ad-hoc ruby-arel ruby -- ruby -e "puts require 'arel'"
true

(I'm pretty sure the "true" means that it worked)

→ guix environment --pure --ad-hoc ruby-nokogiri ruby -- ruby -e "puts require 'nokogiri'"
true

** With a different version of ruby

→ guix environment --pure --ad-hoc ruby-arel ruby <at> 2.1 -- ruby -e "puts require 'arel'"
/gnu/store/gdg5m75axmrciwh3zhfnsc038q349ymg-ruby-2.1.10/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- arel (LoadError)
	from /gnu/store/gdg5m75axmrciwh3zhfnsc038q349ymg-ruby-2.1.10/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
	from -e:1:in `<main>'

→ guix environment --pure --ad-hoc ruby-arel ruby <at> 2.1 -- ruby -e "puts require 'nokogiri'"
/gnu/store/gdg5m75axmrciwh3zhfnsc038q349ymg-ruby-2.1.10/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- nokogiri (LoadError)
	from /gnu/store/gdg5m75axmrciwh3zhfnsc038q349ymg-ruby-2.1.10/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
	from -e:1:in `<main>'


* Alternative

** With the version of ruby used to build the gem

→ guix environment --pure --ad-hoc ruby-arel ruby -- ruby -e "puts require 'arel'"
true

→ guix environment --pure --ad-hoc ruby-nokogiri ruby -- ruby -e "puts require 'nokogiri'"
true

** With a different version of ruby

→ guix environment --pure --ad-hoc ruby-arel ruby <at> 2.1 -- ruby -e "puts require 'arel'"
true

→ guix environment --pure --ad-hoc ruby-nokogiri ruby <at> 2.1 -- ruby -e "puts require 'nokogiri'"
/gnu/store/gdg5m75axmrciwh3zhfnsc038q349ymg-ruby-2.1.10/lib/ruby/2.1.0/fileutils.rb:250:in `mkdir': Read-only file system @ dir_s_mkdir - /gnu/store/jxmi5lr8dbll3pzlzwkafpd9mj1wwxma-profile/lib/ruby/vendor_ruby/extensions/x86_64-linux/2.1.0-static (Errno::EROFS)
	from /gnu/store/gdg5m75axmrciwh3zhfnsc038q349ymg-ruby-2.1.10/lib/ruby/2.1.0/fileutils.rb:250:in `fu_mkdir'
        ...


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?

[Message part 2 (application/pgp-signature, inline)]

Previous Next

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