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

[Christopher Baines]

On Sat, 5 Aug 2017 13:59:56 +1000
Ben Woodcroft <address@hidden> wrote:

> Hi Chris, sorry for the delay on this.

No problem :)

> On 22/07/17 20:06, Christopher Baines wrote:
> > On Thu, 20 Jul 2017 09:39:13 +1000
> > Ben Woodcroft <address@hidden> wrote:
> >  
> >> Hi Chris,
> >>
> >>
> >> [..]
> >>
> >> 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:  
> OK, excellent.
> 
> >> 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.  
> Is "package-mapping" sufficient?

I don't think so. The ruby used is in the case of the ruby-build-system
is an argument to the build system, so you need to traverse part of the
dependency graph, altering the arguments of packages using the
ruby-build-system.

Or, perhaps do the transformation at a lower level abstraction than the
package record...

> >> 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  
> Ah, OK. I hadn't realised there was support for this baked into Ruby 
> itself. Seems obvious in hindsight.
> 
> If all Ruby dependencies build with this change, then the change
> seems reasonable to me, details aside.

Ok, does anyone know a good process for testing if lots of packages
build? I think I've heard of Hydra building branches?

pgpshy7tsXM6O.pgp
Description: OpenPGP digital signature