It is perhaps the most significant step, although I would consider Reuse input lock files · Issue #7730 · NixOS/nix · GitHub to be essential, and the legacy flat lock to be undesirable to keep support around in perpetuity.
Other desirable changes can probably be done in an incremental way, but forgive me if I overlook something.
We do need to distinguish between two kinds of stability. This is somewhat unique to Nix.
- Design stability: which behaviors can we commit to? Nix should keep producing the same derivation hashes and output hashes over time, as part of its reproducibility promise. This makes “stabilized” behaviors rather permanent, which is a huge risk for an underfunded(??) project.
- Operational stability: does it crash? bugs?
We have problems in both areas. They are orthogonal but correlated problems, as fixes to operational stability may expose problems in the design.
As a brief example, we’ve had a case recently where users were using flake inputs to fetch submodules. This is completely unnecessary since 2.26, and it only worked for them because their working directory happened to coincide with the flake root. Sensitivity to the working directory instead of base directory is bug, so here you see an interaction between the two kinds of stability that we discussed.
If we had committed to the 2.25 behavior of flakes by blessing it as stable, we would have to implement a completely unnecessary feature which would even require some architectural changes, removing the separation between fetchTree and the base directory concept, forever making call-flake.nix and the native code that interacts with it more complicated.
Indeed if Determinate were to keep compatible with such a misfeature, we should not accept it upstream.
We have reached contradiction. Q.e.d. I guess. Determinate Nix will have to diverge.
Furthermore they’ve painted themselves into a corner, because they’ve just made part of the community disagree with their approach to stabilization.