From: Ben Woodcroft <b.woodcroft@uq.edu.au>
To: "Christopher Baines" <mail@cbaines.net>,
"Ludovic Courtès" <ludo@gnu.org>
Cc: 27438@debbugs.gnu.org
Subject: [bug#27438] [PATCH] Specify native search path for all ruby packages
Date: Thu, 20 Jul 2017 09:39:13 +1000 [thread overview]
Message-ID: <cd64e36f-2e18-ad95-c4f1-aadd76884431@uq.edu.au> (raw)
In-Reply-To: <20170716183705.18b5025e@cbaines.net>
Hi Chris,
On 17/07/17 03:37, Christopher Baines wrote:
> On Thu, 22 Jun 2017 06:40:17 +0100
> Christopher Baines <mail@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@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
next prev parent reply other threads:[~2017-07-19 23:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-21 6:36 [bug#27438] [PATCH] Specify native search path for all ruby packages Christopher Baines
2017-06-21 6:38 ` [bug#27438] [PATCH 1/3] gnu: ruby-1.8: Fix search path specification Christopher Baines
2017-06-21 6:38 ` [bug#27438] [PATCH 2/3] gnu: ruby-2.2: " Christopher Baines
2017-06-21 6:38 ` [bug#27438] [PATCH 3/3] gnu: ruby-2.3: " Christopher Baines
2017-06-21 11:47 ` [bug#27438] [PATCH] Specify native search path for all ruby packages Ben Woodcroft
2017-06-21 13:12 ` Ludovic Courtès
2017-06-22 5:27 ` Ben Woodcroft
2017-06-22 5:40 ` Christopher Baines
2017-07-16 17:37 ` Christopher Baines
2017-07-16 17:40 ` [bug#27438] [PATCH] guix: build: ruby-build-system: Install to the vendor directory Christopher Baines
2017-07-19 23:39 ` Ben Woodcroft [this message]
2017-07-22 10:06 ` [bug#27438] [PATCH] Specify native search path for all ruby packages Christopher Baines
2017-08-05 3:59 ` Ben Woodcroft
2017-08-05 21:55 ` Christopher Baines
2017-08-06 7:17 ` Ben Woodcroft
2017-06-21 13:10 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cd64e36f-2e18-ad95-c4f1-aadd76884431@uq.edu.au \
--to=b.woodcroft@uq.edu.au \
--cc=27438@debbugs.gnu.org \
--cc=ludo@gnu.org \
--cc=mail@cbaines.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).