Stability promise, reprodubility properties

roberth commented 4 months ago

Problem

It's unclear what are Nix's stability and reproducibility promises, or how successfully we've kept them.

E.g. question raised by @physics-enthusiast

Is there an official guarantee or implicit understanding that “pure-nix” function return values are absolutely stable?

But also what do we promise about other components than the language? E.g. also guarantees about stability of store level functionality.

Proposal

A page about stability and reproducibility.

It should answer the above questions, and contain some of the here:

“pure-nix” function return values

They are meant to be stable, except for bugfixes and functions behind a feature flag.

We have on this occasion allowed an existing function to be more strict (iirc by mistake, initially) for the benefit of better error messages, but only because it does not produce a different result (denotationally, and modulo errors and other bottoms), it does not produce real world problems, and reverting the change would regress the quality of error messages. Another instance where behavior has changed is fetchGit, because it had reproducibility problems. That was a bug.

It should generally be ok to introduce more laziness, except of course in primops that are about adding strictness, and it is also not ok to add laziness at the cost of other behaviors (i.e. laziness is not an excuse to make changes to other behaviors such as the denotational semantics).

Checklist

[x] checked latest Nix manual (source)
[x] checked open documentation issues and pull requests for possible duplicates

Priorities

Add :+1: to issues you find important.

nixos-discourse commented 4 months ago

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/stability-of-function-return-values-in-nix/45124/2

fricklerhandwerk commented 4 months ago

Triaged in Nix team meeting

@edolstra such documentation is always welcome
@fricklerhandwerk have to slice it somehow, it's a large surface to cover
@roberth could start with the language
- @fricklerhandwerk: why the language? it has the largest surface area
- @roberth: the store seems hard to talk about clearly, Nix is mostly experienced through the language
- @fricklerhandwerk: ideally we'd have a minimal spec or "eduational" implementation to have something that conveys intent. otherwise it's almost impossible to draw the line to say what's a bug and what is not
- @roberth: "correct" behavior is somewhere between such an ideal spec and the Nix we have (and has been used by many people for a long time). I don't think it's feasible that we can make the decision of correct behavior objectively, mechanically testable, but we should at least state our goals
@edolstra: probably would be best if somebody writes a proposal as a starting point, so we can discuss that

NixOS / nix