Adding an attribute to a locked input is a breaking change

[roberth]

Describe the bug

https://github.com/NixOS/nix/pull/5385 added the dirtyRev attribute, which is rejected by Nix versions < 2.16.

A similar situation will arise whenever previously unknown attributes are added to the lock.

On the one hand this error seems redundant because of narHash. However, it may be unclear how the attributes should be treated.

Steps To Reproduce

1. Lock a dirty input with Nix 2.17
2. Evaluate again with Nix <= 2.16
3. error: unsupported Git input attribute 'dirtyRev'

Expected behavior

dirtyRev and the other attribute are just ignore? Not sure.

nix-env --version output

Additional context

Maybe it should be breaking because of

• #6530

This is unfortunate. Should the lock file have an field that's open for extension? For metadata that must not affect the value of the fetched file system objects, but is added to the returned attributes. This might be a flake level thing instead of a fetcher level thing, although libfetchers is responsible for getting that metadata. Maybe in-between? libfetchers provides a meta attr in which such attributes are nested. So not a flake thing after all, but still something that's easily discerned by the libfetchers user.

Of course in some cases breaking is the only sensible thing to do, though it will require everyone to upgrade their Nix.

Priorities

Add :+1: to issues you find important.

[sedlund]

I received this error when running nixos-install --flake using a nixos 22.11 iso that was available on the vps provider, to install my system flake that was locked with current unstable.

The error message error: unsupported Git input attribute 'dirtyRev' wasn't clear to me what the problem was.

Searching for it led me here to realize I could remove the lock generated from the newer nix and continue.

[roberth]

Removing dirtyRev only affects the dirtyRev attribute, and not the fetched contents, so the impact of removing it (e.g. by hand) is zero if nothing looks at the attribute, and probably minor otherwise.

[roberth]

Maybe in-between? libfetchers provides a meta attr in which such attributes are nested. So not a flake thing after all, but still something that's easily discerned by the libfetchers user.

I believe a meta field in the lock nodes is the way to go. That way, all evaluators can trivially agree on what the metadata is. The meta attributes must not be returned by fetchTree, because we've seen that they're subject to change. If we do return them from fetchTree we should only return them on explicit request for forward compatibility. E.g. fetchTree { type = "git"; ...; metaAttrs = ["rev", "dirtyRev"]; }. That way incompatible versions can still fail as they should, and future versions only return the attributes that are expected, not polluting the return value with unexpected attributes.