Doesn't it make evaluation impure ? What "${/nix/store/6vjwsyv4il8f9jm3wylbzmbbsa70qc33-hello-2.10}" evaluates to depends on whether hello is already present in the store.

I ran into this again today. This problem is easily solved with toString in most cases, but that's not obvious and can cause confusion. Given that it uses the semantics from isStorePath I feel like this is not a hacky special case, but I'll close this if the consensus is that it is.
/cc @NixOS/nix-core

@symphorien Indeed, however ensuring the path exists is pretty straightforward, eg. nix-store -r /nix/store/6vjwsyv4il8f9jm3wylbzmbbsa70qc33-hello-2.10. The specific case I use this for is reproducing issues with a known good/bad version of a package without having to figure out the exact package set and expression used to build it.

I also needed to work around this behaviour with builtins.storePath, conditioned on lib.isStorePath:

  system.extraSystemBuilderCmds = let
    # make sure store paths are not copied to the store again, which leads to
    # long filenames (https://github.com/NixOS/nix/issues/1728)
    nixpkgs_str = if lib.isStorePath pkgs.path then builtins.storePath pkgs.path else pkgs.path;
  in ''
    ln -sv '${nixpkgs_str}' "$out/nixpkgs"
    echo '${pkgs.path}'
  '';

The intention is to pin nixpkgs to the last version that was explicitly passed in through NIX_PATH, which may or may not be a store path.

I marked this as stale due to inactivity. → More info

I closed this issue due to inactivity. → More info