From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: Foreign packages and reproducibility (formerly Re: [PATCH] gnu: Add ruby-nokogiri) Date: Wed, 2 Mar 2016 11:33:26 +0100 Message-ID: References: <20150714090613.GA1523@thebird.nl> <20160217223708.GA7805@thebird.nl> <56C4FCB6.2080108@uq.edu.au> <20160218062534.GA9060@thebird.nl> <87io1i48k5.fsf@elephly.net> <56C9A4A3.9070602@uq.edu.au> <20160221120520.GB29139@thebird.nl> <20160221172231.GA30227@thebird.nl> <20160221173127.GA30263@thebird.nl> <20160222125127.GA1440@thebird.nl> <20160223185231.GA8112@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54687) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ab468-0006EP-56 for guix-devel@gnu.org; Wed, 02 Mar 2016 05:33:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ab463-0002kX-Tr for guix-devel@gnu.org; Wed, 02 Mar 2016 05:33:40 -0500 Received: from pegasus.bbbm.mdc-berlin.de ([141.80.25.20]:57980) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ab463-0002k6-Hi for guix-devel@gnu.org; Wed, 02 Mar 2016 05:33:35 -0500 In-Reply-To: <20160223185231.GA8112@thebird.nl> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Pjotr Prins Cc: "guix-devel@gnu.org" Pjotr Prins 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=E2=80=99s not a bad idea! But it may cause problems in this situati= on: * 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=E2=80=99d have to freeze the whole closure of the ruby pac= kage expression to keep it stable. When we commit to master we don=E2=80=99t separate updates affecting ruby from those that simply add new packages for ruby gems. As a result you wouldn=E2=80=99t 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 =E2=80=9Cruby=E2=80=9D in the dependency graph with a particu= lar store item (e.g. =E2=80=9Cpgks1l9cl696j34v9mb35lk8x6lac3b0-ruby-2.2.4=E2=80=9D), 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