`builtins.storeDir` should return a path, and not a string

[Ericson2314]

Is your feature request related to a problem?

Yes: #11503

Proposed solution

In general, we don't know where the store is on the root file system. We can model this by saying the portable/pessimistic assumption is that it doesn't exist on the root filesystem at all!

How can we access the store directory, then? builtins.storeDir can instead of returning a string, return a path. Path literals today always are relative the root file system, but that is not how they work internally (thanks to the parts of lazy trees we've already merged). Instead they are relative a virtual file system (which could be a host OS directory or something else, like a git tree). We make builtins.storeDir refer to / in that filesystem.

For back-compat, we can still have toString builtins.storeDir do what is does today, but this should e.g. be prohibited in Nixpkgs (restricted mode for Hydra). (And in general, we might consider this a candidate for a "purer evaluation" mode).

Going back to #11503, what about builtins.filterSource? I think the paths it gives to be filtered should always be relative to to the virtual file system in question (there is no other good option, pretty sure we've done that already on the various lazy fetching branches). So the filtering functions won't see /nix/store/.... either.

Additional context

• Flake paths should use virtual store directories #9852 is similar

• On Windows it could in fact be that the store really isn't to be found on the root filesystem at all. For example, if the current drive (a Windows notion) is D:, and the Nix store is in N:, then /foo/bar is interpreted D:\foo\bar: it is not possible with the Unix-style syntax that the Nix language currently uses for paths to refer to N: at all!

Alternatives

I didn't think about the back-compat implications of this. If we can't change builtins.storeDir, then we can simply create a new one, e.g. builtins.storeDirAsPath. Deprecating the old one (if we even want that) is out of scope.

---

Add 👍 to issues you find important.

CC @puffnfresh

[roberth]

This would have to be a new primop - not worth a breaking change.

[nixos-discourse]

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

https://discourse.nixos.org/t/2025-01-08-nix-team-meeting-minutes-207/58523/1

[roberth]

Isn't storeDir supposed to refer to the logical store dir? I don't think that one is a problem.

$ nix eval --expr builtins.storeDir --store /nix/store?root=$HOME/mnt/nixos
"/nix/store"

If the physical path leaks elsewhere, then that's a problem, but builtins.storeDir doesn't seem to be it.

[Ericson2314]

@roberth this is about providing logical file access. builtins.storeDir + "/..." won't work, and any builtins.realStoreDir would be impure.

[roberth]

storeDir is not a well-behaved immutable file system object though, so I doubt that we should represent it that way.

I wouldn't mind known store paths (ie storeDir children) to be representable with a path value, in particular because that makes it impossible to accidentally readDir storeDir and such, with x + "/..".

Presumably these path values will "${}"-interpolate to their logical store path strings?
Such a behavior would be in line with lazy paths, but not e.g. "${/nix/store/...-foo}", i.e. interpolating an absolute (or system) path value that happens to point into what might be the storeDir.
Such path values are bad anyway, because they refer to store paths by their "real path" instead of letting that be handled by Nix itself. This seems to agree with your goal. Both absolute paths and real paths (which are absolute) are by default impure.

Should derivation outputs also be path values?