What are your thoughts about flake stabilization?

[lucasew]

Question

Today, at least me, suggest everyone coming to Nix to take a look on flakes, but everyone eventually has to deal with the showstopper to enable nix-command and flakes as an experimental feature.

The last nix-command breakage, at least the last one I noticed, was the one to update specific inputs that changed a little.

What are your thoughs about the road to remove these feature flags so it is enabled by default?

Candidates I'd like to get an answer from

No response

Reminder of the Q&A rules

Please adhere to the Q&A guidelines and rules

[mschwaig]

I am in favor of making the flakes and nix-command experimental features the default experience for users soon, and then stabilizing them afterwards.

I think because the old CLI was so stable, we are very attached to the idea of getting everything about the new CLI and flakes totally right from the start. To the point where we are sitting on these things for 4 and a half years now, which creates a whole bunch of other issues and uncertainties in the ecosystem.

There is a wide range of things we can do to make sure users have a good experience between the extremes of

• 'every CLI command should still work the same way in a couple of decades' and
• 'we abandoned it or made extensive changes to the design, and now all the flakes you wrote are useless'

So we should ask ourselves not only

• how can we stabilize flakes and the CLI over time?, but also
• how can we make those features available to users as the default user experience in months, not years?, and
• how can we do it in a forward-looking way that makes subsequent stabilization not that painful in practice?

[Gabriella439]

The flakes and nix-command features should no longer be marked as experimental. We already see a lot of pushback on any proposed breaking changes to either of those features, which indicates to me that they're no longer experiments and people already expect them to be stable interfaces.

One example of what I'm talking about is the repl-flake experimental feature, which is yet another feature flag that should not have been necessary if the nix-command and flakes feature flags were truly viewed as experimental. The whole point of marking nix-command and flakes as experimental was so that we could iterate on them and make breaking changes if necessary, but if we're guarding further breaking changes behind even more feature flags then that indicates to me that our tolerance for breakage has gotten low enough to stabilize those features.

[cafkafk]

I personally believe that NixCpp misuses the "experimental feature" concept as a way to avoid the headache of providing stable releases (same has been seen recently with the notion that NixCpp is a "reference implementation"[1]).

Instead, NixCpp should stop feature gating behavior that has obviously seen wide adoption. At the same time, it should add feature gates for the most unpolished parts, such as nix-bundle.

Then, new breaking changes should be feature gated as well, and when they're ready to be shipped, or a substantial portion of the community has changed over to the new behavior, the gate(s) should be removed on the next major version. I'd suggest making new major versions on some reasonable release schedule, e.g. in time with the nixpkgs xx.05 and xx.11 releases, or perhaps just once a year at either of those.

There guarantees would lead to a much more stable experience. Also, it would grow confidence, and perhaps restore trust in the ecosystem, and ideally, we'd live to see a time where nixpkgs had a NixCpp version above 2.18 as the default. I've seen plenty of veteran maintainers recently jokingly suggest moving nixpkgs to Lix, and if the NixCpp team wants to avoid that, I think the best route is by being a better alternative, not policy[2] as I've heard suggested elsewhere.

[1]: Other famous examples of this cop-out are Mastodon and Element, to the detriment of the quality of those projects.

[2]: I would be strongly opposed to any top-down restrictions about which Nix implementation should be the default in nixpkgs, it should be the one serving the contributors and users, and community at large the best.

[nyabinary]

I fully support stabilizing both nix-commands and flakes.

More specifically, I want to stabilize flakes as a “v0” version. This allows us to establish a stable foundation while identifying and addressing the design flaws and limitations that have persisted in flakes up to this point. Looking forward, I envision a “flakes v1” that could incorporate breaking changes to resolve these issues, while maintaining the flexibility and utility that flakes bring to the Nix ecosystem.

For a “v1” release, I believe it should be marked under experimental features to allow for more iterative and transformative improvements without impacting the stability of “v0.” By separating “v0” and “v1” in this way, we can ensure that flakes continue to evolve, guided by community feedback, without sacrificing the stability that users currently rely on. I believe this approach will let us experiment and refine while keeping the existing system robust for current users.

[getchoo]

I was a bit on the fence about this at first, but as I continued writing my response...I kinda changed my mind. I do not believe Flakes should be stabilized yet.[^*]

For reference, I moved to Flakes pretty quickly after I started using NixOS in ~2 months. I vastly preferred it over the stable CLI, using basic fetchers for dependencies, and most of all I enjoyed the organization it gave Nix projects by introducing (mostly) standard outputs for consumption. But as I went further down the rabbit hole over the years, I came to better understand some of the flaws of the current implementation and the very large room for improvement.

Some of my favorite sources for describing these are @lf-'s amazingly titled blogpost, "Flakes aren't real and cannot hurt you: a guide to using Nix flakes the non-flake way", @lheckemann's talk at last year's NixCon, "What Flakes needs (technically)", and @samueldr's blogpost, "Nix Flakes is an experiment that did too much at once…". And while I may not agree with every single point brought up in these, I highly recommend anyone reading this to go give them a read/listen/watch; they're great!

In any case, some points from the above sources I feel strongest about are:

• Lack of configurability
  • Some workarounds for this exist...but they are messy to say the least. See nix-systems
• The Flake registry
  • While useful, this introduces an impurity in running CLI commands and (non-locked) Flakes
  • nix flake update for example may result in Nix resolving completely different upstream sources depending on the system's state
  • nix run nixpkgs#<package> will have a different result depending on when and where you run it
  • Lix developers now vendor the online flake registry. This is a good way to solve this problem now, but I'd like to see this functionality completely deprecated in regards to declared Flake inputs; this would be much better if it were CLI only
  • lheckemann proposed a --pure flag that would enforce explicit references in CLI commands, which would in turn allow for backwards compatibility in current commands, but also ensure the reproducibility of those using --pure
• Filesystem shenanigans
  • Copying all of a Flake's source tree into the store creates a massive issue for projects at a scale, to the point where Flakes may not be feasible for them at all
  • We also have massive footguns
  • Lazy trees fix most of these issues, but still aren't quite ready yet. I believe this is one of biggest blockers to widescale Flake adoption and thus stabilization

Some of these may be done without introducing backwards incompatibilities, while others not so much. I think this is the power of the current "experimental" flag, though -- even if it we haven't used it as much as we could. We still have room to make these changes and not push out a feature still containing a number of core issues with the promise of it being "production ready".

However, I am very well aware of how many users depend on Flakes in production environments already -- including myself in probably 99% of personal and collaborative projects. That's why I strongly believe breaking changes must be made thoughtfully and only where necessary, but still encouraged in order to reach an actually stable state. As lheckemann said in his talk, we must avoid changing widespread patterns that would break evaluation of Flakes (unless they fix ambiguities (see the point on registries above)) and "the errors that get thrown should come with clear explanations of what was broken, why, and how to make things work again."

Lastly, any effort to stabilize Flakes should heavily involve the Nix team. Quoting samueldr from the above blogpost:

It is important to let the Nix maintainers team decide on how to handle this situation, as they themselves will handle maintaining it. Deciding to mark them "stable" today is pushing a large load on their back.

[^*]: But I would like to see it done sooner than later. Enabling them by default (similar to the Determinate Systems installer) is also something I would want to explore, and giving them something at least close to the amount of documentation for stable Nix on resources like nix.dev should be a priority given their widespread use

[tomberek]

Most of what needs to be said has been expressed above. I'll only add that the Nix team's current approach to this problem is: (1) trying to fill the remaining gaps in nix-command and (2) to finalize the semantics of fetchTree, a cornerstone of flakes.

Oh, and if anyone would like to pursue fixing any of these, or any other outstanding Nix issues, feel free to reach out or contact the team!

[phaer]

I see this as one of the more urgent issues of the ecosystem:

It's not only an annoyance for users but for new-comers, the question why a feature that's so widely used in the community isn't available in the default config pushes some of nix historic(?) governance issues right into their face, far too early in their journey into nix.

Additionally, at this point in time any breaking changes to flakes could cause such widespread breakage across the community, that they would need to be handled with great care on a release engineering level, providing migration advice and such.

I am aware of at least some of the flaws in the current implementation, @getchoo provided a great list of links in their response for those interested in details. Remaining issues around fetchTree seem to be the biggest to me.

The SCs role here would be to

• Check with the nix team what they need for fetchTree stabilization specifically, and also in general. Try to agree to a date where we would stabilize the current behavior and decide to eat the maintenance cost as a project.
• Discuss in detail what the consequences of in terms of maintenance and generally were if we would grandfather-in the current implementation. I suppose this greatly depends on how stable paths stay for evaluating existing expressions.
• In any case, coordinate with the documentation and marketing teams to ensure all breaking changes are easily accessible so that users understand what broke why and how to fix it.
• Consider a fundraiser for this effort specifically if it would help the effort.

[roberth]

Stabilization implies a long term promise that includes the stability of the hashes produced by Nix. This has wide ranging consequences that make it even harder to fix the numerous issues with Flakes.

As a member of the Nix team I would consider supporting a statement that Flakes are ok to adopt, but with a carve-out for minor changes to such things as CLI flags and changes for the sustainable stabilization of fetchTree, and limited forward compatibility for the lock file; e.g. you may have to update Nix within 7 months in order to accept lock files from newer Nix releases.

I question the technical value of such a statement, but it could help inform users' decisions.

If you want Flakes to stabilize sooner, and you don't mind getting into the nitty gritty of fetching, locking, or the CLI UX, please get in touch with the Nix team. :heart:

[proofconstruction]

It's crucial to differentiate between the changes to the nix command, the flake.nix and flake.lock file specifications, and the various other things people mean by "flakes". @samueldr has a great write-up of this here, which I broadly agree with. In summary, the bundle of changes commonly called "flakes" did both too much and not enough, and is a clear example of what-not-to-do and how-not-to-do in the future.

While I consider the nix command changes to be important improvements in usability (though we still need to do something about nixos-rebuild), and would like to see them land in stable nix, actually accomplishing this is difficult at least in part because of the way the changes landed in unstable and how they're tangled up with the other stuff.

For my own systems, I've used flakes for years (it's a decent-enough entrypoint to multi-system configs), and have even contributed flake.nix files to various other projects, but I actually recently started to refactor my personal configs to remove flake.nix and flake.lock in favor of an npins solution that I find conceptually nicer, though in need of polishing.

As a functional programmer and Nix user, I am frustrated that the flake.nix specification defines neither a function nor a valid Nix expression. There's nothing there to stabilize.

[Infinidoge]

I think the law of "Good Enough" applies here. Flakes are a de-facto standard already, and them being marked as experimental causes additional friction. Flakes have many flaws, the posts pointed out by getchoo ("Flakes aren't real and cannot hurt you [...]" in particular) are all good discussions about what those flaws are. But despite that, they are overall quite stable, and I've been using them as the foundation of my NixOS configuration for years now.

I think Lix has the best approach here: Both Flakes and non-Flakes are important and need to be maintained. Flakes needs to inherit some of the ease of usability that non-flakes has (A good recent example being the "unflake" template I recently added to my config, which makes a devshell using a NIX_PATH pinned from my system flake), and non-flakes should be able to benefit from the purity, locked dependencies, and ease of management (mostly-ish) of flakes. Flake schemas to me feels like the next logical evolution, but that's a topic outside of the scope of stabilization. Flakes need room to evolve, and I think nyabinary's approach of having 'now' be "v0", and working on improving flakes be "v1" makes sense.