The Great Nix Flake Check

A developer working on "unflake" — a userspace reimplementation of Nix flakes — is digging into the project to make sure it behaves like upstream. It has been reported that flakes don’t have a formal specification, are barely documented, and that upstream maintainers allegedly aren't entirely sure how some parts work either. The result: anyone trying to reimplement flakes is left reverse-engineering behavior from the implementation and its tests. Frustrating? You bet.

What’s happening

The author of unflake says compatibility with the canonical flake behavior is the goal, which means understanding quirks and edge cases rather than reading a spec. That turns development into a detective story: run the official code, observe outputs, poke at it until the shadows reveal a pattern. It’s slow, brittle work — and not the fun, productive kind of creativity developers usually sign up for.

Why it matters

This isn’t just an academic exercise. Nix flakes are positioned as a way to make reproducible, composable builds easier — but without clear documentation or a stable contract, third‑party tooling and alternative implementations will keep stumbling. The ecosystem suffers: tooling is harder to build, users face surprises, and migration or interoperability plans stall. Sound familiar? It’s the same story open source projects tell when the public API is really just “how the code happens to behave.”

If you want the full blow-by-blow, the original write-up is here: https://goldstein.lol/posts/great-nix-flake-check/. The takeaway is blunt: implementers like unflake can push the ecosystem forward, but someone needs to turn those behavioral notes into a proper spec — sooner rather than later.

Sources: goldstein.lol, Lobsters