guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Foreign packages (formerly Re: [PATCH] gnu: Add ruby-nokogiri)


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]