A snapshot of the guix repository is similar to a snapshot of Google's "google3" monorepo. It differs, in that rather than containing the full source of a specific version of every software package, it encodes instructions on how to obtain and build a specific version of each package. This has some tradeoffs; the size of Guix's repo is greatly reduced, and it is easier for Guix to import new packages by simply wrapping the build systems they already use, rather than re-implementing the build logic with blaze/bazel. On the other hand, the decentralized nature makes it hard for any one actor to make a breaking change. At Google, if you want to make a breaking change in a library, you can update all the users of that library in the same commit. I think that this feature is actually overrated, because it is often complicated by a need to preserve the ability to roll back a release.
With guix, I know that I am able to build every package in the distribution, and I don't need to lookup how to use cmake or bazel or ninja or meson or dune or whatever the author decided to use. I don't have to figure out how to obtain and build the right versions of C libraries that a package links to. I just use `guix build`. I think that is a wonderful thing. Conversely, I am also free to use any build system that's implemented in guix/build-systems. I think guix could also greatly lower the barrier to contributing to free software projects. Since a guix package typically encodes * How to obtain the software * How to build the software * (usually) how to test the software * (usually) its source repository One could develop a `guix contribute <package>` subcommand or standalone script that would implement the following workflow: 1. Obtain the source and unpack it into a writable working directory, skipping downstream patches and snippets. 2. Drop the user into a shell with the build and test inputs present. Perhaps with the scripts $PWD/.guix/test and $PWD/.guix/build added to run the build and test actions as needed. 3. After the user has made changes, and maybe signalled completion somehow, run the tests and build all outputs. 4. Once the user exits, output a diff that's suitable for git send-email. I recently used guix to make a one-line change to the dovecot-pigeonhole package. Initially I tried to do this without guix, and had difficulties using autoconf/automake. So instead, I made my changes, captured them with `git diff`, and then used the `--with-patch` option of `guix install` to build and install the modified version. It wasn't too hard, but it could have been easier. It may have not been worth the effort in this case for someone new to guix, but the nice thing is I could take the same steps to modify any piece of free software for which a guix package exists, regardless of the build system in use. David
