Although Nix flakes are currently marked as experimental, the on-the-ground experience of actually using flakes has been quite stable since their initial release in November 2021. Even the so-called “unified CLI,” also marked as experimental, has seen remarkably few breaking changes in that time. Evidence from GitHub strongly suggests that the Nix community is moving in the direction of flakes and the unified CLI en masse. And I hear from more recent Nix adopters over and over again that flakes were crucial to their learning journey.
I believe that flakes are stable, and I’m not alone. My position is that the experimental flag should have been removed ages ago—or never introduced in the first place. I don’t think that flakes need a lengthy stabilization process. Nix users of all stripes have been using flakes in production for years and to great effect. The “experimental” label needs to be removed. Flakes are a proven technology and deserve to be officially recognized as such.
Nonetheless, flakes in their current form have detractors, and those detractors make some reasonable points. I want to address three common criticisms of flakes.
- Source explosion.
Many of you have probably seen the article about 1,000 instances of Nixpkgs.
It’s a good read but I disagree with the conclusions.
With evaluation caching and the functional nature of Nixpkgs, source explosion is generally mitigated using the
followsmechanism built into flakes, which reduces the number of unique Nixpkgs instances involved in an evaluation. And by embedding further support for version boundaries that FlakeHub introduces, the Nix locking mechanism can even make reasonable dependency unification choices automatically. - Cross-compilation. Some say that cross-compilation using flakes isn’t great. Flakes and the unified CLI indeed don’t offer specific support for cross-compilation—but the old Nix CLI and channels didn’t offer direct support either. Improving cross-compilation in Nix is a large though highly worthy project. But it has nothing to do with flakes and thus no bearing on stabilization.
- Lockfile format.
I’ve seen discussions around this and the terms are always vague.
Sometimes, lockfiles can become rather large.
I don’t have a lot of sympathy for this problem, when Nixpkgs’ git history is gigantic and computing is relatively cheap.
Nonetheless, this problem is also being worked on and does not need to be solved prior to stabilization, as a new mechanism can increment the
flake.lockversion field.
I think that #1 is a fair criticism and an area where I’d like to see forward progress. But I do not see it as a compelling reason to continue marking flakes as experimental. We can declare flakes as stable today and find ways to address source explosion under the banner of flakes as a stable feature of Nix.
Could flakes be improved? Yes. I do acknowledge that there are some fundamental issues that should be addressed—this is true of just about any technology. But the “experimental” flag should not, in my view, be interpreted as “unstable.” It would be reckless to break backwards compatibility in how flakes are evaluated, especially locked flakes. Any changes to flakes should be made with due care and respect for the sake of the thousands of users incorporating Nix into their daily workflows.
Determinate Systems is committed to maintaining that compatibility in partnership and in collaboration with the Nix maintenance team. We shouldn’t let yet another NixCon, yet another year go by having only a vague sense of what it’ll take to get flakes stabilized. It’s time to call good enough good enough. I’m calling on the Nix team to remove the experimental flag by the end of the year and to thereby open a new chapter in Nix’s history and pave the way for other worthy goals.
