Re: Is Guix suitable for large monorepos?

[Blake Shaw <blake@sweatshoppe.org>]

[-- Attachment #1: Type: text/plain, Size: 5350 bytes --]

Hiya guix,

I tried to reply to this quickly while I was travelling, but what started
with "sorry to brief" quickly became quite long -- nonetheless I think
theres some important insight into using Guix effectively in production I'd
still like to share, so will finish it off now that I'm back:

==
I'm traveling at the moment so excuse me for being brief but I saw
Katherine's message about long source rebuilds and want to try to chime in
quickly.

I had a difficult experience of using Guix in production against a
medium-large C++ repo (openFrameworks) in June when substitute availability
was failing a good deal of the time, along with several broken packages
"infecting" a decent area of oF's ~140 package dependency graph, to add to
the mayhem.

Considering it was a moment I needed to move fast, I created a hotfix
branch where I could disable tests, do quick gnarly fixes and keep moving.
Its worth noting that working like this you can really knock out a lot of
package "fixes" quickly, I was able to do 10 in a day, but also this was
while deploying a video mapping project so security wasn't a huge concern.

This initially worked decently, in terms of maintaining project momentum
while racing towards a delivery. But when it came to installing on the
servers and the laptop onsite, which came with their own difficulties, the
build times started weighing in more than I was able to handle.

I had been considering starting a Cuirass instance but was worried it would
be too difficult to figure out in constrained time. At some point I thought
"you know what lets try this just not sleep and see if cuirass can be a
solution, and if its immediately confusing shelve it and move on". But the
truth was...

...Cuirass was one of the quickest parts of the Guix system I've hit the
ground running with.

I really wish I had deployed it from the outset, and I surely will on all
future projects. Within a day of fiddling with it I had my linode providing
substitutes of not only my dependency graph, but also generations of three
different systems, as well as VMs. After the first night of building i
suddenly had lightning fast substitutes available and problems upstream
faded away. In short, had I used Cuirass from the get-go I would have saved
myself from a massive amount of difficulty.

The difficulty with reproducibility in production is that it you're
constrained for time, building back to a month old generation can be out of
the question. I think there is a "reproducibility ideal" that we and the
Nix folks often allude to as our reality, where "you just roll back", but
the conditions of production can often make this unfeasible. Before my next
gig I plan to automate things so that I can easily tag commits in git that
will trigger system generations to be built and stored as QEMU images that
I can quickly access as need, which I think will bring me closer to this
ideal. I'll be sure to share when it comes time (but currently taking a
little break from being deep in the weeds).

Also, my apologies that I haven't been contributing much... an experiment
with self-hosting my email earlier this year ended with a borked email
server and I have yet to setup gnus & git with this email address. Will be
rolling up my sleeves in the coming weeks :)

Happy hacking!
b



On Fri, Jul 22, 2022, 21:26 Katherine Cox-Buday <cox.katherine.e@gmail.com>
wrote:

> 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
>
>

[-- Attachment #2: Type: text/html, Size: 6576 bytes --]