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 wrote: > jgart 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 > >