all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Pjotr Prins <pjotr.public12@thebird.nl>
To: Pjotr Prins <pjotr.public12@thebird.nl>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Re: Foreign packages and reproducibility (formerly Re: [PATCH] gnu: Add ruby-nokogiri)
Date: Sun, 21 Feb 2016 18:31:27 +0100	[thread overview]
Message-ID: <20160221173127.GA30263@thebird.nl> (raw)
In-Reply-To: <20160221172231.GA30227@thebird.nl>

Another option would be have a symlinked profile for every ruby interpreter with
the full hash

/var/guix/profile/per-ruby/ziy7a6zib846426kprc7fgimggh8bz97-ruby-2.1.3/

which contains symlinks to the libraries/gems installed against that ruby.

NOW we only need to tell the interpreter where to find the libraries using this
path. This could actually be patched in trivially at installation time.

(I think this is rather exciting, though again I have the feeling
someone has thought of this before).

Pj.


On Sun, Feb 21, 2016 at 06:22:31PM +0100, Pjotr Prins wrote:
> I am thinking about this again. It is relevant for all interpreters.
> 
> The real pain is that between Ruby interpreters the profile can be shared which
> contains a path to the modules, e.g. say ruby-nokogiri. Currently you can run
> 
>   guix package -i ruby ruby-nokogiri
>   ruby -e "require-2.2.1 'nokogiri'"
> 
> next update ruby to a new (minor) version 
> 
>   guix package -i ruby-2.2.2
> 
> and run again
> 
>   ruby -e "require 'nokogiri'"
> 
> will work.
> 
> which is wrong because nokogiri was built against the first ruby interpreter.
> It is a problem from the view point of reproducible software execution.
> 
> To prevent this we should *not* allow modules (i.e. nokogiri) in the
> profile.
> 
> But now a user doing a simple
> 
>   ruby -e "require 'nokogiri'"
> 
> will fail, because the interpreter does not know where nokogiri
> is. This is wrong because users should be able to access installed
> gems (that is the point of having gems!).
> 
> One suggestion is wrappers and runpaths. I.e. wrap the invocation of
> 'ruby' with a script that will pass in the path to all installed gems.
> 
> Q1: is there a limitation to the length of such a path (generally a
>     bash variable)?
> 
> Q2: would the wrapper be updated every time a new gem gets installed?
>     How can we be sure it is deterministic? Installation order may matter.
> 
> Q3: can we query guix on-the-fly for paths to all leaf nodes that
>     depend on a ruby? That way a wrapper could be installed
>     once. Would that be too slow? How can we be sure it is
>     deterministic?
> 
> I do not know how nix solves it exactly, but I do know they use a
> wrapper script.
> 
> Finally, I do think that most Ruby gems should propagate ruby
> itself. Only rarely are gems executables. Mostly they are libraries,
> which implies you need to run ruby to run them. Right? It does not
> make sense to install a Ruby library without the ruby interpreter.
> 
> Pj.
> 

-- 

  reply	other threads:[~2016-02-21 17:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-13 13:09 [PATCH] gnu: Add ruby-nokogiri Pjotr Prins
2015-07-13 13:24 ` Ricardo Wurmus
2015-07-14  9:06   ` Pjotr Prins
2015-07-14 14:25     ` Ricardo Wurmus
2016-02-17 22:37     ` Pjotr Prins
2016-02-17 23:05       ` Ben Woodcroft
2016-02-18  6:25         ` Foreign packages (formerly Re: [PATCH] gnu: Add ruby-nokogiri) Pjotr Prins
2016-02-21 11:16           ` Ricardo Wurmus
2016-02-21 11:50             ` Ben Woodcroft
2016-02-21 12:05               ` Pjotr Prins
2016-02-21 17:22                 ` Foreign packages and reproducibility " Pjotr Prins
2016-02-21 17:31                   ` Pjotr Prins [this message]
2016-02-22 12:51                     ` Pjotr Prins
2016-02-23 18:52                       ` Pjotr Prins
2016-03-02 10:33                         ` Ricardo Wurmus
2016-03-02 18:50                           ` Pjotr Prins
2016-02-21 12:02             ` Foreign packages " Pjotr Prins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160221173127.GA30263@thebird.nl \
    --to=pjotr.public12@thebird.nl \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.