Re: Is Guix suitable for large monorepos?

[Katherine Cox-Buday <cox.katherine.e@gmail.com>]

jgart <jgart@dismail.de> writes:

> Is Guix suitable for large monorepos?

I use Guix against a large mono-repo, and there are a few
difficulties.

I should mention that I am not using Guix in the typical fashion with
fixed commits (packages are pointed at HEAD and I don't use checksums).
For my purposes, it's useful for me to build HEAD, although sometimes I
use transformation options if I'm interested in a specific branch or
commit.

I've defined a package for the entire repo and then individual packages
for the constituent projects which inherit from the repo package.

For new commits:

- Updating the source take a long time.
- Indexing the entire repo takes a long time.
- Copying over the entire tree to the build directory is unnecessary and
  takes time.

Sometimes I want to build a local change I haven't committed anywhere,
so I use the --with-source option. The problems are the same, but
they're exacerbated.

A happy medium I've landed on is to build some binaries outside of Guix
and then use packages that are defined in terms of the binaries. These
packages use patchelf to get everything linked correctly. This allows me
to reify these packages into Guix while keeping the standard workflow
from a programming language.

I've also considered a phase that, after checkout, deletes all files not
relevant to the project to lessen the burden of copying things over for
building.

So, in my opinion, these issues are not really Guix's fault, and it does
a pretty good job all things considered. I think Guix used in a CI/CD
pipeline (which I guess means cuirass) would handle mono-repositories
wonderfully and do exactly what I want: reproducible, verifiable,
builds. Guix as a development tool in these situations is still useful,
but has some things that make it a little difficult to work with.

Maybe someone has some ideas to improve things?

-- 
Katherine