I’m finding that any attempt to obtain a store path from within an existing store path, incorrectly returns the current directory. For example:
$ cd /nix/store/jhfm45g19nwcqg6z1vd8pi4kv6ahrxhl-package_a
$ nix build --no-link --print-out-paths "path:/home/chris/local_dir#package_b"
$ nix eval --raw "hg+https://myrepo.com/package_b_repo#package_b`
$ nix path-info "hg+https://myrepo.com/package_c_repo#package_c`
This feels a little dangerous, since these commands return incorrect values rather than erroring, and executables that are in the nix store may run these commands and may assume that they can do some from their pwd (ie, the store path at which the executable is stored). This is the situation that caught me out, as I was running some python utility code that over the course of its execution calls various nix functions.
I can’t reproduce…
$ nix build --no-link --print-out-paths nixpkgs#hello.outPath
I can’t reproduce it now either, at least not with
nix build. Probably at this point it sounds like I was hallucinating, but this used up two hours of my morning today and definitely really happened. If I use
nix eval on a flake, I still get something odd:
$ nix eval --raw "path:/home/chris/repo_a#package_a"
error: argument '/nix/store/ac8dn942x1j48bfnng8xz634430ykcxa-aeson-pretty-0.8.9' cannot be evaluated
but I’m not sure if/how
nix eval’s behaviour is defined when eval-ing flakes like this anyway.
Wow, I can definitely reproduce:
$ cd "$(nix build --no-link --print-out-paths nixpkgs#hello)"
$ nix build --no-link --print-out-paths florp/
This only happens when the “florp/” string is not a flake reference, so the “/” is needed, but otherwise any string does this! It look like this is a bad interaction of Nix figuring out that
realpath florp/ is
/nix/store/2g3jazymqbjw9c390c3b7vw8xq3r8iny-hello-2.12.1/florp, then “building” that, making sure it exists.
This is definitely worthy of a bug report!