[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: |
Sun, 16 Jul 2017 18:37:05 +0100 |
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... 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, address@hidden 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 address@hidden -- 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 address@hidden -- 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 address@hidden -- ruby -e "puts
require 'arel'"
true
→ guix environment --pure --ad-hoc ruby-nokogiri address@hidden -- 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?
pgp4RIMmF9RTT.pgp
Description: OpenPGP digital signature
- [bug#27438] [PATCH] Specify native search path for all ruby packages,
Christopher Baines <=