Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stability promise, reprodubility properties #10694

Open
2 tasks done
roberth opened this issue May 13, 2024 · 2 comments
Open
2 tasks done

Stability promise, reprodubility properties #10694

roberth opened this issue May 13, 2024 · 2 comments
Labels
documentation idea approved The given proposal has been discussed and approved by the Nix team. An implementation is welcome.

Comments

@roberth
Copy link
Member

roberth commented May 13, 2024

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

Priorities

Add 👍 to issues you find important.

@nixos-discourse
Copy link

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 fricklerhandwerk added the idea approved The given proposal has been discussed and approved by the Nix team. An implementation is welcome. label May 15, 2024
@fricklerhandwerk
Copy link
Contributor

fricklerhandwerk commented May 15, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation idea approved The given proposal has been discussed and approved by the Nix team. An implementation is welcome.
Projects
Status: ⚖ To discuss
Development

No branches or pull requests

3 participants