Pjotr Prins <pjotr.publi...@thebird.nl> 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
