Add setting 'allow-dirty-locks'

[edolstra]

Motivation

This allows writing lock files with dirty inputs, so long as they have a NAR hash. (Currently they always have a NAR hash, but with lazy trees that may not always be the case.)

Generally dirty locks are bad for reproducibility (we can detect if the dirty input has changed, but we have no way to fetch it except substitution). Hence we don't allow them by default.

Fixes #11181.

Note that currently you have to enable allow-dirty-locks both when locking and when using the lock file. The latter may be overkill. We could accept any existing lock entry so long as it has a NAR hash.

Context

---

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[NiklasGollenstede]

Nice! A flag with the note "don't push/publish this" seems far.

Just to confirm: Once a flake lock is created with --allow-dirty-locks, other nix commands (that don't modify the flake lock) will (maybe warn but) not fail if there are !.isLocked() but .getNarHash() != null inputs in the lock file?
I.e., I only need to supply --allow-dirty-locks when writing the flake.lock?

[edolstra]

I only need to supply --allow-dirty-locks when writing the flake.lock?

No, currently you also need it when using the flake. But as I noted in the PR description, maybe we should lift this restriction.

[NiklasGollenstede]

Silly me. I stopped reading after "Fixes #11181".

I would recommend / welcome it that the flag is only used when locking. While one shouldn't get "dirty" locked flakes from others, I don't think that a preemptive refusal to work with them is helpful. And if one created the dirty flake, then that's already acknowledged.
Also, as mentioned in #11181, there are (nix-wrapping) APIs where one can pass flakes, but not (all) other nix flags. And "forcing" users to set this via user/global system nix settings would hardly be what the flag wants to achieve.

Maybe print a warning that a dirty input is being used (though too many warnings also have a numbing effect).
In case that users somehow obtain a dirty / narHash only input and the matching store path is not available it would be very nice to have an error that explains this.

[paumr]

First of all: Thanks @edolstra for the implementation of this fix!

@NiklasGollenstede just to offer a different perspective:

"allow-dirty-locks" should ease the development workflow, it should by no means be used in production.
Thus, one might want additional safeguards for that (like checking for this flag while using lock files).
If this turns out not to be necessary the restriction can always be lifted, however it's not possible to add this restriction at a later point - since this would be a breaking change.

Regarding the mentioned APIs not supporting the passing of nix-flags:
This popped up in the context of #11181 since it was an unexpected regression, breaking mentioned tools.
With this PR users would have two options:

• set this setting system-wide to support unmaintained tools (which they should phase out anyway)
• fix their tools / add the required flags