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

[Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> OK, back on the topic of conflicts between interpreters and modules:
>
> I realise the current system is fine as is!
>
> Sometimes it is good to go for a cycle run in the cold ;)
>
> GNU Guix does the right thing. It builds isolated packages, including
> interpreters and modules. Next it puts them in a profile.
>
> Now the key insight is that it is *not* Guix' responsibility when
> people mess up their profiles. It is easily possible, even with emacs,
> to mess up the profile.
>
> Also, Ruby allows for minor version mixing of modules. It is a Ruby
> problem. They should fix that.
>
> We could have the interpreter test modules for being true dependencies
> and we could test the interpreter for belonging with a module. But the
> thing is, it is not necessary.
>
> Users can easily use different profiles for different Rubies. They
> just need to be aware. I can create a profile named
> ~/.guix-pgks1l9cl696j34v9mb35lk8x6lac3b0-ruby-2.2.4 if I want to. It
> is good enough. That profile will contain the modules I install with
> that Ruby.

That’s not a bad idea!  But it may cause problems in this situation:

    * install that ruby
    * install ruby packages built with that ruby
    * wait until the ruby recipe is updated (or changes hashes because
      of a change to the inputs)
    * install another ruby package (built with the new ruby variant)

There is no way to fix the ruby variant when installing new ruby
packages.  You’d have to freeze the whole closure of the ruby package
expression to keep it stable.  When we commit to master we don’t
separate updates affecting ruby from those that simply add new packages
for ruby gems.

As a result you wouldn’t be able to add new gems to your profile without
mixing Ruby versions.

I guess we might eventually use the dependency rewriting framework to
replace any “ruby” in the dependency graph with a particular store item
(e.g. “pgks1l9cl696j34v9mb35lk8x6lac3b0-ruby-2.2.4”), so that you can
even install new ruby gem packages with the very same version of ruby
that you already have in your profile.  (Currently we can only override
explicit inputs, not inputs that are added implicitly by the build
system.)

For convenience we might also want to have per-profile settings that
allow us to specify default overrides, so that no matter what ruby gem
you add to the profile it will always use a fixed variant of Ruby to
build it.

The same applies to R.  It would be good if we could ensure that all
additional packages in a profile reference the same interpreter version,
because at runtime we only have one interpreter available.

~~ Ricardo