From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: Guix mentioned in Journal of Open Source Software (JOSS) Date: Tue, 14 Jun 2016 10:56:27 +0200 Message-ID: References: <20160614074712.GA29135@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]:46297) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCk9J-00013c-9y for guix-devel@gnu.org; Tue, 14 Jun 2016 04:56:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCk9E-0000p5-Cv for guix-devel@gnu.org; Tue, 14 Jun 2016 04:56:41 -0400 Received: from venus.bbbm.mdc-berlin.de ([141.80.25.30]:46927) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCk9D-0000of-Ta for guix-devel@gnu.org; Tue, 14 Jun 2016 04:56:36 -0400 In-Reply-To: <20160614074712.GA29135@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" To: Pjotr Prins Cc: guix-devel@gnu.org Pjotr Prins writes: > We published a paper on GeneNetwork which uses Guix for deployment: > > http://joss.theoj.org/papers/10.21105/joss.00025 Congratulations on getting the paper accepted! > The review process is online and you can see there were some hickups > with Guix: > > https://github.com/openjournals/joss-reviews/issues/25 It=E2=80=99s good that this was documented. > (1) Roel has suggested we should script the binary installation. I thin= k > that is a fine idea. That was hurdle one. > > (2) Hurdle two is fixating the package tree. I would really like a=20 > > git pull --version HASH =E2=80=9Cguix=E2=80=9D or =E2=80=9Cgit=E2=80=9D? > where HASH pulls a git HASH version of the gnu/packages tree and > compile the scheme files. That would help binary reproducibility > without having to check out the full tree. What is the problem with checking out the =E2=80=9Cfull tree=E2=80=9D? T= he biggest part of Guix is the packages tree and it=E2=80=99s using things that are defin= ed in the smaller part, so they are tightly coupled. Currently, the easiest way to get to a previous version is to do git reset --hard cabba9e where =E2=80=9Ccabba9e=E2=80=9D is the hash of the version you want to ha= ve. For the central installation of Guix here at the MDC I suggest people publish the result of these two commands along with their package manifests: git -C /gnu/remote/guix describe git -C /gnu/remote/guix-bimsb describe This gives them two hash-like strings for the unmodified Guix upstream repo and our local repository. Others trying to reproduce our state would just need to clone the two repos and reset them to the given description strings. > We don't need to roll-back the guix client, though that would be nice > too and should be possible with Guix. Just give it a different binary > name, how about guix-HASH? When using guix-HASH it would automatically > use the older guix and the older package tree. Since they are coupled =E2=80=9Cgit reset --hard ...=E2=80=9D already doe= s this. But I agree that it would be nice to have more than one installation of Guix that allows users to switch versions without having to deal with the git user interface. > Or something along that vein. > > (3) I also think the default GUIX key should just be available. Why mak= e > guix authorize an extra step? When I install guix, I WANT it. What default key do you mean? Looking at the review I see that this is about your caching server=E2=80=99s public key, is it not? In that case = I think having to authorize an external provider of binaries is a feature. Hydra, I think, is authorized by default. ~~ Ricardo