From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dYrJS-0005K8-U5 for guix-patches@gnu.org; Sat, 22 Jul 2017 06:07:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dYrJO-0003Pa-AX for guix-patches@gnu.org; Sat, 22 Jul 2017 06:07:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:49247) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dYrJO-0003PR-6m for guix-patches@gnu.org; Sat, 22 Jul 2017 06:07:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dYrJN-0000NE-Qu for guix-patches@gnu.org; Sat, 22 Jul 2017 06:07:01 -0400 Subject: [bug#27438] [PATCH] Specify native search path for all ruby packages Resent-Message-ID: Date: Sat, 22 Jul 2017 11:06:30 +0100 From: Christopher Baines Message-ID: <20170722110630.19b5fce0@cbaines.net> In-Reply-To: References: <0c3c92c6-05ca-bb36-2f24-69077033e91f@cbaines.net> <878tkliix9.fsf@gnu.org> <6a666d6f-f2c2-d786-8fda-422ab28867ca@cbaines.net> <20170716183705.18b5025e@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/gjk.WBqXMXzplh1Nlgr1BlC"; 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 Cc: 27438@debbugs.gnu.org --Sig_/gjk.WBqXMXzplh1Nlgr1BlC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 20 Jul 2017 09:39:13 +1000 Ben Woodcroft wrote: > Hi Chris, >=20 >=20 > On 17/07/17 03:37, Christopher Baines wrote: > > On Thu, 22 Jun 2017 06:40:17 +0100 > > Christopher Baines wrote: > > =20 > >> On 22/06/17 06:27, Ben Woodcroft wrote: =20 > >>> 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. > >>> > >>> Chris, what is your experience? Did you propose the patch because > >>> you ran into a particular issue? =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. > >> > >> 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. =20 > > [..] > > > > 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? =20 > Thanks for working on this. A few thoughts: >=20 > 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: =E2=86=92 guix environment --container --ad-hoc ruby -- irb ... for 1 packages... done in 0.028 s=20 irb(main):001:0> ENV =3D> {"PS1"=3D>"\\u@\\h \\w [env]\\$ ", "TMPDIR"=3D>"/tmp", "TEMPDIR"=3D>"/tmp", "TMP"=3D>"/tmp", "TEMP"=3D>"/tmp", "HOME"=3D>"/home/chris", "PATH"=3D>"/gnu/store/2dh34pi9yjq17qf1bw3dmgcdpri20fjs-profile/bin", "GEM_PATH"=3D>"/gnu/store/2dh34pi9yjq17qf1bw3dmgcdpri20fjs-profile/lib/ruby= /vendor_ruby", "GUIX_ENVIRONMENT"=3D>"/gnu/store/2dh34pi9yjq17qf1bw3dmgcdpri20fjs-profile", "LINES"=3D>"76", "COLUMNS"=3D>"190"} irb(main):003:0> require 'rake' =3D> true irb(main):004:0> require 'minitest' =3D> true > In general, except for some special circumstances, we don't support > old versions of software. To fix the issue that you are encountering=20 > 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=20 > https://lists.gnu.org/archive/html/guix-patches/2017-04/msg00126.html),=20 > but I worry in general about the resources required to support older=20 > 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 ruby@2.1 -- 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 ruby@2.1 in place of whatever ruby they might be using. > The gem-home procedure in ruby-build-system will now return an > incorrect path, I think. Good spot. I'll have a look at that. > Perhaps I'm slow, but what are the advantages of the "vendor_ruby"=20 > method over exporting multiple GEM_PATHs as Ludo and I suggested?=20 > 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 > Apologies if this comes across a little negative, I'm just trying to=20 > consider all the issues. Thanks again for your efforts on this. No need to apologise, I too think its important to consider the details of the support for ruby, which is not something I'm particularly knowledgeable on. --Sig_/gjk.WBqXMXzplh1Nlgr1BlC Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEPonu50WOcg2XVOCyXiijOwuE9XcFAllzI6ZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcACgkQXiijOwuE 9XfeXA/8ChoAjDCFmIRZi9hpXC491LayHkMyA8VUSdnDgQndpbvpbxGTSToUp2BB uFdZIZWGeTsdyshZD+3joXgrHok7Zia8K7FO1kdU44hxMqkBvT+4lRQSKnxVQqdi U1gSFBAELgWS39zo/WAX5bobssBkR5fUqQpAdLOV/iigFamDOy09RbislSgDzr9P OWnGz5odYTHza8ED8/rWMiROtnviRKxCCzifWkTKP61c86TOoSXf/9J9QXgOne2k eyVWyIwcKE7FPNPYJQAFHim1EwCyTS7NEqYMOEWR0avgwq0fs1DX6I8sTT+CxpCy ++VhGX7z/vatNOlImYsHqzuiLlbXXzpTKoPXtMcXr0FTuTOX9qBe480YkOO8XdJ7 LEFthBfUa+YVJlQYVcvZZjynV19rRUC6yOvwy/o+x2+mr/ghnib4WO0FSjon3661 aGzC20ToVQ/ZKhV0AfZGjuSx7XzhY7BJaa03rCQVm1ZSvXbp/53n/ffbuY/kL0De AXT0PbNZF7BLJPPyBC0Y72OI864GylO/JQC8haOEjWTGtmP8a1AUrjAPnQUiJJZO tVHI1mET0eef4zs0E44NDfWq7ffBVq1HovT1ReZoz/71LkbR7S1Wj5qUwWTQWiJ0 outgu2rBrfh0sYNCiLG9pxQUscsidiPruEx0VeuaWDhbG6SEP04= =xTQ7 -----END PGP SIGNATURE----- --Sig_/gjk.WBqXMXzplh1Nlgr1BlC--