From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57426) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dWnUc-0004rF-HX for guix-patches@gnu.org; Sun, 16 Jul 2017 13:38:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dWnUY-0002C0-Ha for guix-patches@gnu.org; Sun, 16 Jul 2017 13:38:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:40000) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dWnUY-0002Bp-EE for guix-patches@gnu.org; Sun, 16 Jul 2017 13:38:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dWnUX-0003Vb-VP for guix-patches@gnu.org; Sun, 16 Jul 2017 13:38:01 -0400 Subject: [bug#27438] [PATCH] Specify native search path for all ruby packages Resent-Message-ID: Date: Sun, 16 Jul 2017 18:37:05 +0100 From: Christopher Baines Message-ID: <20170716183705.18b5025e@cbaines.net> In-Reply-To: <6a666d6f-f2c2-d786-8fda-422ab28867ca@cbaines.net> References: <0c3c92c6-05ca-bb36-2f24-69077033e91f@cbaines.net> <878tkliix9.fsf@gnu.org> <6a666d6f-f2c2-d786-8fda-422ab28867ca@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/DVvOWoZ31TztI/Yfn9yLlF9"; protocol="application/pgp-signature" 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: Ben Woodcroft , Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 27438@debbugs.gnu.org --Sig_/DVvOWoZ31TztI/Yfn9yLlF9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=C3=A8s wrote: =20 > >> Ben Woodcroft skribis: > >> =20 > >>> On 21/06/17 16:36, Christopher Baines wrote: =20 > >>>> Without specifying this explicitly in each definition, the > >>>> GEM_PATH is inherited and the version is that of the inherited > >>>> package.=20 > >>> 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 > >>> =20 > >> Or should the search path spec include both lib/ruby/gems/2.2.0 and > >> lib/ruby/gems/2.4.0, in this order? =20 > > Exactly. > >=20 > > Chris, what is your experience? Did you propose the patch because > > you ran into a particular issue? =20 >=20 > 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. >=20 > 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/ . >=20 > 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. >=20 > 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@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 =E2=86=92 guix environment --pure --ad-hoc ruby-arel ruby -- ruby -e "puts = require 'arel'" true (I'm pretty sure the "true" means that it worked) =E2=86=92 guix environment --pure --ad-hoc ruby-nokogiri ruby -- ruby -e "p= uts require 'nokogiri'" true ** With a different version of ruby =E2=86=92 guix environment --pure --ad-hoc ruby-arel ruby@2.1 -- ruby -e "p= uts require 'arel'" /gnu/store/gdg5m75axmrciwh3zhfnsc038q349ymg-ruby-2.1.10/lib/ruby/2.1.0/ruby= gems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- a= rel (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 `
' =E2=86=92 guix environment --pure --ad-hoc ruby-arel ruby@2.1 -- ruby -e "p= uts require 'nokogiri'" /gnu/store/gdg5m75axmrciwh3zhfnsc038q349ymg-ruby-2.1.10/lib/ruby/2.1.0/ruby= gems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- n= okogiri (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 `
' * Alternative ** With the version of ruby used to build the gem =E2=86=92 guix environment --pure --ad-hoc ruby-arel ruby -- ruby -e "puts = require 'arel'" true =E2=86=92 guix environment --pure --ad-hoc ruby-nokogiri ruby -- ruby -e "p= uts require 'nokogiri'" true ** With a different version of ruby =E2=86=92 guix environment --pure --ad-hoc ruby-arel ruby@2.1 -- ruby -e "p= uts require 'arel'" true =E2=86=92 guix environment --pure --ad-hoc ruby-nokogiri ruby@2.1 -- ruby -= e "puts require 'nokogiri'" /gnu/store/gdg5m75axmrciwh3zhfnsc038q349ymg-ruby-2.1.10/lib/ruby/2.1.0/file= utils.rb:250:in `mkdir': Read-only file system @ dir_s_mkdir - /gnu/store/j= xmi5lr8dbll3pzlzwkafpd9mj1wwxma-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? --Sig_/DVvOWoZ31TztI/Yfn9yLlF9 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEPonu50WOcg2XVOCyXiijOwuE9XcFAllrpEFfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcACgkQXiijOwuE 9Xeqog/+KDNrA/My2SYrvejv5McInH58TORCiqPpQqOxuwUfEGNELF/0JyPFoDfM W9zVHaXKU3RcxYGlfVC/yXp9K7nNGFl9zABNfmCo1wsbgcofJAyYPqXHKsShOWe7 y6WCnybBCvgcDrUAXJAMary1Ox211DQofGJxf+wCEHkDVW1zNkCAZZ/B5YKTrqhE C7GRjY5s5MzarqnxoSu4X+TFLMeEO/5b8dtWDtHEgvmmuLO+t3su+6X+LNPrP+ip AgtT1idgLAzc/2zE+kFtQZo+LPR6qycfMkMems+xJRYVEDR5m2JhucKzMsccn9H4 UE7nZU1TJvtMSVs8MeyjlmyW2SBsLs6oYdSO/8S7gSzFykSHoD4svsu2CmQA8b5l Ef9mmX29SefLLPUu49IZnctywjiBVOYLaduIk7q6cTUkk+LDEbaKfRXXlrQ258gz R3a56LdVyeQr7+1bj9VeUEjFugzxvQBofILdchQlnjiuOr+T1LN0n1+cu+xQl1/8 TmlY8sq93FQDtrUXuQobuYyIBwuCHC12SBBBcjy2HwbdE0m5KuNQ9bE0LmWTtiD3 b5tO+blw+D/o+6iuJicoaI6uEtMAa+1UV+QI8lWTmzx8Sbor+EfDejTKG0ZLe8pX FNRL0dXD2yof5mtIgUWbQS3IJwCA+dMJmrQF4c4kpgusGBolP9k= =EPDc -----END PGP SIGNATURE----- --Sig_/DVvOWoZ31TztI/Yfn9yLlF9--