Pjotr Prins <[email protected]> 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”. > 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 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). 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
