unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>
To: Pjotr Prins <pjotr.public12@thebird.nl>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Re: Foreign packages (formerly Re: [PATCH] gnu: Add ruby-nokogiri)
Date: Sun, 21 Feb 2016 12:16:58 +0100	[thread overview]
Message-ID: <87io1i48k5.fsf@elephly.net> (raw)
In-Reply-To: <20160218062534.GA9060@thebird.nl>


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”.

> 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

  reply	other threads:[~2016-02-21 11:17 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 [this message]
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
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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=87io1i48k5.fsf@elephly.net \
    --to=ricardo.wurmus@mdc-berlin.de \
    --cc=guix-devel@gnu.org \
    --cc=pjotr.public12@thebird.nl \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).