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

[Ben Woodcroft <b.woodcroft@uq.edu.au>]

On 21/02/16 21:16, Ricardo Wurmus wrote:
> Pjotr Prins <pjotr.public12@thebird.nl> 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