Re: Guix mentioned in Journal of Open Source Software (JOSS)

[Ricardo Wurmus]

Pjotr Prins <address@hidden> 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’s good that this was documented.

> (1) Roel has suggested we should script the binary installation. I think
> that is a fine idea. That was hurdle one.
>
> (2) Hurdle two is fixating the package tree. I would really like a 
>
>   git pull --version HASH

“guix” or “git”?

> 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 “full tree”?  The biggest part
of Guix is the packages tree and it’s using things that are defined 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 “cabba9e” is the hash of the version you want to have.  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 “git reset --hard ...” already does 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 make
> 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’s 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