Complex end-to-end tests using Guix G-expressions
16 points by FedericoSchonborn
16 points by FedericoSchonborn
I really wish guix had the weight nix has thrown behind it in terms of userbase. Nonguix seems like a unfortunate bandaid on what feels like a better designed language.
Deterministic packaging really needs a large maintainer AND userbase to work.
Guix seems pretty interesting, but I'm not convinced that its worth it to rewrite all my services. That said, I only have a surface level understanding of shepherd, maybe it is good enough to replace systemd for my uses.
Everything else can be translated fairly directly, but switching service management systems is tough and there's not really a good way to do high level service definitions since its like 80% implementation details lol
I did a similar thing with Nix many years ago, with scripts in various languages depending on their strengths (Racket for manipulating s-expression data, Python for stats and plotting, R for some off-the-shelf statistical tests, etc.) all the way through to producing PDFs.
Annoyingly, Microsoft later bought github.com, which caused many devs to move their repos elsewhere and delete them off github.com. Since my processing steps were hard-coding the github.com URLs of their dependencies, the old commit IDs referenced in those PDFs would no longer build (at least, without trickery like pre-populating store paths downloaded from elsewhere) :-(
The only things I've found that aren't suitable for wrapping like this are benchmarks, since (a) the results aren't reproducible/deterministic, and (b) they can be affected by things like concurrency, which can't be easily controlled from within a build (we can impose it from outside, but it's still awkward). For that, I had Nix generate the scripts to be run; then I'd run them standalone, and commit the results to a repo as raw data files for subsequent processing.