nixpkgs-multiverse: fast mode
18 points by vbernat
18 points by vbernat
This is remarkably cool. The most actually useful Nix hack I've seen in ages.
That was my main "gripe" with the previous solution: if you pin a lot of packages, you pull many versions of nixpkgs and evaluate them. Instead, @fzakaria fetch it from the cache if you don't need to override anything.
My gripe is if this is true:
It remains mostly an index, some JSON, and a
fetchTreebehind a memo table.
then, why are flakes involved? Why not stick to simpler tools that might actually become stable vs. experimental, politically-mired features? If it doesn’t technically require flakes, then there is needed reframing for these reading materials. …To which, if it’s only fetching Nixpkgs, then the already-stable builtins.fetchTarball can be used without involving experimental fetchTree too.
It works also without flakes. I believe I have examples in the doc. There is not input to this "flake" so it works in the old style as well.
old style
Stable* style, my friend. This is the code that actually works without any unstable/experimental features.
I was a long-time flakes holdout.
I talk about it here: https://fzakaria.com/2026/07/18/how-to-piss-off-your-nix-friends (If you want to see the talk live I linked it to https://fzakaria.com/2026/08/16/defcon34-wrap-up which I gave at https://nix.vegas)
tl;dr; flakes are (still) "meh" but I also appreciate direction by the pre-BDFL.
I’ve read that post before & I still think the messaging matters tho. To call these things “old” or “legacy” frames the stable code as something to stop using, which I don’t think in the correct framing. I have been on both sides of this argument & agree at the “meh”, but seeing deployment at scale need to to stick to flake = false; just to get something reasonable to work with—with transitive dependencies creating cycles, misuse of follows, & mismanagement of developer-only tooling as well as plain ol’ overlays always being the more powerful abstraction anyhow—I think it’s important not only to support non-flakes, but push back against framing that this will be the future when it’s a kitchen sink approach now mired in politics. It’s very easy to design highly-coupled code passing self in places that could have been modular, or the mounds of abstractions to had away the system for loop (the thing you are supposed to be explicit about)… I think this matters to newcomers to start with the fundamentals that aren’t flakes before they understand modular, composable design patterns to avoid the pitfalls—& to label as “old” isn’t gonna make folks understand that flakes, at least in NixCpp, aren’t going to merged anytime soon. These coupled patterns are copied by the LLMs too which is just making everything worse :|
I also included a "solve" API to provide a single nixpkgs that provides the version you seek. It's not a minimal number of nixpkgs so it's polynomial .
If you want to jump right to the multiverse: https://nixmultiverse.com/ (It includes search and docs, but the stats page is particularly interesting too https://nixmultiverse.com/?view=stats)
I wonder if this can also solve the problem of specifying which node is bound to pnpm that I install.
I don't think this solves that. Do note that the nodejs being used is exposed as pnpm.passthru.node-slim, if that helps.