From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dXyZa-0003X0-PI for guix-patches@gnu.org; Wed, 19 Jul 2017 19:40:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dXyZX-0000xm-K2 for guix-patches@gnu.org; Wed, 19 Jul 2017 19:40:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:45635) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dXyZX-0000xW-G8 for guix-patches@gnu.org; Wed, 19 Jul 2017 19:40:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dXyZW-00006D-DF for guix-patches@gnu.org; Wed, 19 Jul 2017 19:40:03 -0400 Subject: [bug#27438] [PATCH] Specify native search path for all ruby packages Resent-Message-ID: References: <0c3c92c6-05ca-bb36-2f24-69077033e91f@cbaines.net> <878tkliix9.fsf@gnu.org> <6a666d6f-f2c2-d786-8fda-422ab28867ca@cbaines.net> <20170716183705.18b5025e@cbaines.net> From: Ben Woodcroft Message-ID: Date: Thu, 20 Jul 2017 09:39:13 +1000 MIME-Version: 1.0 In-Reply-To: <20170716183705.18b5025e@cbaines.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Christopher Baines , Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 27438@debbugs.gnu.org Hi Chris, On 17/07/17 03:37, Christopher Baines wrote: > On Thu, 22 Jun 2017 06:40:17 +0100 > Christopher Baines wrote: > >> On 22/06/17 06:27, Ben Woodcroft wrote: >>> On 21/06/17 23:12, Ludovic Courtès wrote: >>>> Ben Woodcroft 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