2023-07-31 Nix team meeting minutes #76

thufschmitt · August 9, 2023, 5:10am

`no-absolute-path-literals` experimental feature · Issue #8738 · NixOS/nix · GitHub

@thufschmitt: we might want to have a system for warning flags
@roberth: quite orthogonal, don’t care about the “syntax”
@thufschmitt: this can be implemented as experimental feature first and changed to warning flag later when that feature is implemented

has use cases
interface may need improvement?
generalize throw to arbitrary values? This allows proper programming outside the happy path
- add --exception flag (or similar) to allow use of non-string return values, effectively putting a catch around the evaluator as used by the CLI, so that values can be printed as JSON, a derivation can be built, etc
To be discussed further

@edolstra: Still concerned about optional references like people abusing this to build pluggable derivations that would have undeclared reference to other store paths (and would behave differently depending on the presence of these)
But the fact that it’s all-or-nothing (can’t selectively discard only a subset of the derivations) makes this much less dangerous in that regard
@edolstra: Let’s stabilize this
Agreement

@edolstra would like to have this
- overhaul the lock format
- flake.nix should be authoritative, e.g. no follows info in the lock file
- and reuse lock files as suggested
How to deal with unlocked dependencies?
- would still have to be saved
Does that duplicate lock entries in case of follows?
- no
@edolstra: lock file format will be simpler; essentially a mapping from inputs to their locked equivalents
Backwards compatibility may be tricky
@roberth: It may be possible to apply the new semantics to the current lock file, as a migration path. This won’t have the benefits of the new semantics just yet, but provide forward compatibility
@edolstra: Or we can keep both lock file formats around
@tomberek: Can we prototype this?
@edolstra: Yes, in flake-compat
@roberth: Great for experimentation and experience, iterating the design a bit

@tomberek and @edolstra intend to work on this issue

Not immediately clear what the current and new algorithm are