"lock file contains unlocked input" when using (dirty) git+file:// input

[NiklasGollenstede]

When developing/testing flkes that are primarily inputs to other flakes, I remove the public URL from the including flake.nix's input, making the input indirect, and have a ~/.config/nix/registry.json entry redirecting that to the local repo that I'm editing ("to": { "type": "git", "url": "file:///..." }).
A simple nix flake lock --update-input ... would then suffice for the depedent flake to use the same version of the input flake that you would get when running commands in the input's tree.

Starting with nix v2.21, I get error: lock file contains unlocked input '{"dirtyRev":"...-dirty","dirtyShortRev":"...-dirty","lastModified":17...,"narHash":"sha256-...","type":"git","url":"file:///..."}'.

That is quite unfortunate, because I liked my previous workflow, and I think that the input is actually perfectly locked. Not to anything that is publicly or necessarily persistently available, but I don't think Nix has any chance to ensure that anyway. As with any other locked input, it will either use the exact version specified (in the narHash) or fail if that is not available/obtainable.

Not considering dirty repos as proper locks seems to have been an intentional decision by @edolstra (in 071dd2b).
There are probably cases there that interpretation is indeed not helpful, but as stated above, I think my inputs were perfectly locked before.

Steps To Reproduce

1. Have a flake with input { type = "git"; url = "file:///..."; }
2. Have the local repo pointed to be dirty
3. Run nix flake lock (with or without old flake.lock)
4. See: error: lock file contains unlocked input '{"dirtyRev":"...-dirty","dirtyShortRev":"...-dirty","lastModified":17...,"narHash":"sha256-...","type":"git","url":"file:///..."}

Expected behavior: The workflow described in the first paragraph still works.

nix-env --version output: 2.21.2 (anything past 071dd2b?)

Priorities

Add 👍 to issues you find important.

[roberth]

@edolstra, It seems that 2.21 lock files are causing trouble for older versions such as 2.18 (NixOS 24.05). Perhaps we could re-insert the locked field and only "mark it" for deletion in a future revision of the lock format?

[DavHau]

I'm running into the same issue using nix 2.23.0 after updating from nix 2.20.x.
I had used --override-input with nix 2.20 and nix 2.23 crashes:

error:
… while updating the lock file of flake 'git+file:///home/grmpf/synced/projects/hyperconfig
error: lock file contains unlocked input {"dirtyRev":"bfb7a882678e518398ce9a31a881538679f6f092-dirty","dirtyShortRev":"bfb7a88-dirty","lastModified":1716509168,"narHash":"sha256-T6xYKgn1HRVpucBMPn5iAL4ZYu9WErmvjc1ZPxaSgLY=","type":"git","url":"file:///home/grmpf/synced/projects/github/nixpkgs"}

[nixos-discourse]

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

https://discourse.nixos.org/t/2024-07-03-nix-team-meeting-minutes-158/49097/1

[tmillr]

@edolstra, It seems that 2.21 lock files are causing trouble for older versions such as 2.18 (NixOS 24.05). Perhaps we could re-insert the locked field and only "mark it" for deletion in a future revision of the lock format?

I think it's much more than that. For example, I tried:

rm flake.lock &&
  nix run --no-use-registries github:NixOS/nixpkgs/nixpkgs-unstable#nix -- flake update

in order to recreate my lock file from scratch using the latest nix cmd.

Which gives back:

warning: will not write lock file of flake 'path:/Users/*/.nixpkgs' because it has an unlocked input ('git+file:///Users/*/code/neovim.flake?submodules=1')

and does not write/recreate the lock file.

---

So it appears that my choices are:

1. Don't use a lock file at all. (rather not since this is my system flake)
2. Change the "faulty" flake input to something which doesn't use/consider the git index/worktree?

[nixos-discourse]

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

https://discourse.nixos.org/t/refer-to-a-flake-in-a-local-folder/57000/2

[NiklasGollenstede]

Nix first started marking (unclean tree) git inputs as unclean, then refused to use inputs marked as such and, as @tmillr points out, also (in an even later version?) refuses to lock them at all.

By no means as a permanent solution, but rather as a workaround until, hopefully, Nix's behavior changes, I created a script (nix-flake-update) that uses nix v2.20 to update the lock file, and then jq to "clean" it, before verifying that current nix accepts the lock file.

The script, with further comments how and why it works (and drawbacks), can be found here:
https://github.com/NiklasGollenstede/nix-wiplib/blob/master/pkgs/scripts/nix-flake-update.sh
The flake also experts the script as overlay and package.
Sometimes the script fails the first time I run it, but then success. I haven't investigated that yet.