Why does `nix flake show` try to write a lock file?

Help
1

As I understand, the purpose of a lock file is to list the exact version of each input used by a flake. This is why the lock file contains where the input source is from and its revision hash. (In flakes with many inputs, this could result in many different versions of some dependencies, which is why the .inputs.nixpkgs.follows feature exists to deduplicate versions.) Having all the inputs locked to a version means that the flake is deterministic and reusable: there is no fear that a later version could break, since the rev is pinned in the lock file.

This all makes sense to me, which makes the following behavior of nix flake show confusing. The first command below fails because it can’t write a lock file – but why is it trying to write a lock file at all, when the lock file is right there in the git repo? (I did check that flake.lock was committed to the repo in question.) The second command explains why it’s trying to write a lock file: it’s updating the nixpkgs input to the latest rev. Doesn’t that defeat the whole purpose of a lock file? Why would nix update the dependencies just to display the contents of the flake?

This seems like a pretty obvious bug, so I feel like I must be misunderstanding something above.

$ nix flake show github:nix-community/NixOS-WSL
error: cannot write modified lock file of flake 'github:nix-community/NixOS-WSL' (use '--no-write-lock-file' to ignore)
(use '--show-trace' to show detailed location information)

$ nix flake show github:nix-community/NixOS-WSL --no-write-lock-file
warning: not writing modified lock file of flake 'github:nix-community/NixOS-WSL':
• Updated input 'nixpkgs':
    'github:NixOS/nixpkgs/e8ec26f41fd94805d8fbf2552d8e7a449612c08e' (2022-12-09)
  → 'github:NixOS/nixpkgs/0938d73bb143f4ae037143572f11f4338c7b2d1c' (2022-12-17)
github:nix-community/NixOS-WSL/fab2833c091e059fd75e0c2cd570279500e76351
├───checks
│   ├───aarch64-linux
│   │   ├───nixpkgs-fmt: derivation 'check-nixpkgs-fmt'
│   │   ├───shfmt: derivation 'check-shfmt'
│   │   └───side-effects: derivation 'empty-file'
│   └───x86_64-linux
│       ├───nixpkgs-fmt: derivation 'check-nixpkgs-fmt'
│       ├───shfmt: derivation 'check-shfmt'
│       └───side-effects: derivation 'empty-file'
├───devShell
│   ├───aarch64-linux: development environment 'nix-shell'
│   └───x86_64-linux: development environment 'nix-shell'
├───nixosConfigurations
│   └───mysystem: NixOS configuration
└───nixosModules
    └───wsl: NixOS module
2

It’s not a bug. The lockfile is not up-to-date with the inputs specified in the flake.nix. The nixpkgs input as per flake.nix is github:NixOS/nixpkgs/nixos-22.11, while the lockfile has

      "original": {
        "id": "nixpkgs",
        "ref": "nixos-22.11",
        "type": "indirect"
      }

which is lockfile-ese for nixpkgs/nixos-22.11. The last commit in this PR should’ve been followed up with a nix flake lock.

3

Should be fixed now!

4

Okay, I see that the command works without warnings now, so the issue was indeed with the lockfile being out of date rather than there being a general problem with lockfiles. ty @nzbr

It is still unclear to me why the lockfile couldn’t have been used as-is. Nix was able to identify the un-updated input as being the same nixpkgs input, since it showed an update to nixpkgs rather than seeing them as separate and reporting an unused input in the lockfile and an unlocked input in the flake.