nix flake update outside a flake dir reccommends the use of --no-write-lock-file

[lolbinarycat]

Describe the bug

if you run nix flake update in a directory that does not contain a flake.nix file, it will still update the global cache, but it will give an error about being unable modify the (nonexistant) lockfile, and will recommend --no-write-lock.

nix flake update --no-write-lock produces an error about an unknown option.

Expected behavior

don't reccommend a nonexistant flag

nix-env --version output nix-env (Nix) 2.18.2

Additional context

why is there no documentation for the global flake cache?

if i update a git repo on one device, push to it, then run that repo's flake on another device, i expect it to run the updated flake, not continue to produce the error i just fixed.

Priorities

Add :+1: to issues you find important.

[thufschmitt]

if you run nix flake update in a directory that does not contain a flake.nix file, it will still update the global cache, but it will give an error about being unable modify the (nonexistant) lockfile, and will recommend --no-write-lock.

I don't get that:

$ nix flake update
path '/tmp/tmp.etaols3jMZ' does not contain a 'flake.nix', searching up
error: could not find a flake.nix file

can you share a more precise repro?

why is there no documentation for the global flake cache?

if i update a git repo on one device, push to it, then run that repo's flake on another device, i expect it to run the updated flake, not continue to produce the error i just fixed.

There's no global Nix cache. What exists (and I guess is the source of the confusion) is a global flake registry, that maps flake names to (like nixpkgs) to actual flake references (github:NixOS/nixpkgs in that instance I guess). It's documented (somewhat awkwardly, I agree here). When you lock a flake, the flake.lock is the only source of truth for resolving the dependencies, and nothing else matters

[lolbinarycat]

can you share a more precise repro?

you have to pass an argument to nix flake update, and possibly that argument needs to be a remote flake with a lockfile.

There's no global Nix cache

that doesn't make sense.

cached evaluation is global, and additionally, as far as i can tell, unlocked remote flake sources aren't redownloaded every single time they're evaluated, which is another cache (maybe it's just using the builtin fetcher tarball-ttl for caching?)

[lolbinarycat]

and i know there's a global cache because --refresh invalidates it.

[eclairevoyant]

$ nix run github:nixos/nix -- flake update --flake github:eclairevoyant/pcids
error:
       … while updating the lock file of flake 'github:eclairevoyant/pcids/6ddf0349d91cd3bac9230241bb501d2654f14137?narHash=sha256-9UR8rXpfnAVarGaNruYN6d8aL%2BXbpWCa35Pxc0HZ2/g%3D'

       error: cannot write modified lock file of flake 'github:eclairevoyant/pcids' (use '--no-write-lock-file' to ignore)

$ nix run github:nixos/nix -- flake update --flake github:eclairevoyant/pcids --no-write-lock-file
error: unrecognised flag '--no-write-lock-file'
Try '/nix/store/xylicnq3yx9lqagzw40v40f9myaf3442-nix-2.22.0pre20240419_8c4c215/bin/nix --help' for more information.

So, we shouldn't refer to a flag that (seemingly) doesn't exist anymore?

[thufschmitt]

Thanks @eclairevoyant, that clarifies the issue a lot!

Indeed, flake update disables the --no-write-lock-file flag because it doesn't make sense for such a command. And that means that it doesn't make sense to suggest it. Probably not an easy fix, but PRs welcome to get rid of it.

[eclairevoyant]

Okay, but what does it meant to update a remote flake (i.e. nix flake update --flake <remote-flakeref>)? As far as I can tell, it touches the eval and fetcher caches, though I don't understand the semantics. In other words, I'm not sure what the suggestion should be instead, or if the command itself should behave differently for remote refs.