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