|
From: | Ben Woodcroft |
Subject: | Re: Foreign packages (formerly Re: [PATCH] gnu: Add ruby-nokogiri) |
Date: | Sun, 21 Feb 2016 21:50:59 +1000 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 |
On 21/02/16 21:16, Ricardo Wurmus wrote:
Pjotr Prins <address@hidden> writes:Another issue: for me the main problem with foreign modules in Guix is that they are not completely isolated in the profile. No one caught me out on that yet ~/.guix-profile/lib/ruby/2.2.0/ (in my talk I showed the path). But we symlink against major version numbers. So any Ruby interpreter 2.2.x version will share the same gems. It is not necessarily a problem because the Ruby world is built around this assumption. But when I look at developer support and reproducibility I don't like it much. You can have software running with different Ruby interpreters under the hood - and you won't know it.Do they really reference different variants of Ruby in the background? The ruby-build-system adds the “ruby” package only to the build inputs. I don’t have different “ruby-*” packages in my store right now (after “guix gc”), so I cannot verify this myself. I would be interested to know if references to the “ruby” package are actually retained when building, say, “ruby-nokogiri”.
And either way, I'd argue that just being present in the store doesn't qualify as "installed" for its usual definition.
I realise this is different from what you are saying Ben, but both these problems exist in my mind. I would prefer to isolate the against the full hash in the profile - or at least Ruby version - that way there can be no mixing. E.g. ~/.guix-profile/lib/ruby/pgks1l9cl696j34v9mb35lk8x6lac3b0-ruby-2.2.4/ It does not look as nice in the profile - but who cares.
I'm not sure I follow Pjotr. There is only one GEM_PATH environment variable used by all rubies, no?
I haven’t thought enough about this to have an opinion about this. Generally, though, I dislike to use environment variables to point the interpreter to a prefix where all libraries can be found. I think that it’s up to the libraries themselves to find their dependencies (like it’s done with RUNPATH).
Indeed, please do make progress in the parallel thread about Python...Maybe Ruby is easier though. Simply replace the foo in require 'foo' with the first input where /gnu/store/.../lib/ruby/gems/2.2.0/gems/.../lib/foo.rb is a file, I think. Presumably the reality will be more complex, but does this sound bad Pjotr?
Thanks, ben
Can we avoid all of this by replacing “require "library"” in Ruby source files with “require "/gnu/store/.../path/to/library"”? Would we still need to have a single in-profile prefix for Ruby libs? ~~ Ricardo
[Prev in Thread] | Current Thread | [Next in Thread] |