Re: Building a software toolchain that works

[David Arroyo]

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