Add pure-storepath-builtin experimental feature

[Pandapip1]

Motivation

No consensus has been found as to whether storePath should be considered pure or impure. As such, an experimental feature should be added to allow those that consider the function pure to use it as such.

Context

See #5868.

Heads up: This is my first code change to nix; it's likely I missed something from the contributing document (even though I did read through it), and I couldn't find any documentation about the process of adding an experimental feature in the repo (I was on an airplane with no internet and am just now submitting the PR).

---

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[Ericson2314]

Heh, I would support this. It is sort of "unsure whether to stabilize as de facto stability 2nd time as farce", but shrug.

[Pandapip1]

Should I just link to #5868 as the tracking issue temporarily so that CI is happy? I don't think a 'real' tracking issue is really warranted since it'd be mostly discussions about whether to make storePath pure or not, and we already have that as #5868.

[roberth]

It feels more like a preference to me, which feels comparable to nixpkgs.allowUnfree in terms of the effect it has, and with a potential slight overlap in the kind of thing it prevents.

This seems to be consistent with the lack of a milestone. I think an experiment should be set up to have some sort of outcome, but it seems that in this case it comes down to personal preferences and or the requirements of individual projects.

If we were to make this an individual setting instead, I believe this would have the following benefits over an experimental feature flag:

• no buildup of feature flags that won't be removed
• no migration required when we eventually turn this into a setting anyway
• ability to configure this in flake.nix/nixConfig
• shorter CLI flag

Perhaps worth noting about the disabled setting

• it doesn't make much sense for global configuration, because addToStore is always allowed
• doesn't prevent appendContext, which has a similar effect to storePath, but does not allow use of the path's content in evaluation when in pure mode (i.e. IFD not allowed, but can install a pre-evaluated package or binary store path)

@Ericson2314 @Pandapip1 wdyt?

[Pandapip1]

no buildup of feature flags that won't be removed

The plan would be that this would be removed.

no migration required when we eventually turn this into a setting anyway

I really hope this does not become a permanent setting because otherwise this is something that people have to build around, and that seems bad. This is pretty explicitly something that will only exist while there remains debate about the storePath built-in. Eventually, either it will become pure or impure.

ability to configure this in flake.nix/nixConfig

I'm not entirely convinced this is an upside, but I'm also not entirely convinced it's a downside either.

shorter CLI flag

While this is true, I can't imagine that people would not just have this configured as a global setting.

---

I do not have particularly strong opinions about whether or not it should be a setting or an experimental feature, and I'll just go with whichever result seems to reflect the popular opinion to get this merged faster.

[roberth]

If we're ok to accept the feature when no significant issues are found during the experiment, then indeed that could be a better outcome than a setting.
Also a setting would still be a possibility after the experiment, so this choice is not critical at all.
Unless someone has a convincing argument, I'd be ok to make it experimental, to avoid getting stuck again.

[edolstra]

I feel an experiment wouldn't reveal anything that we don't already know. The issue with builtins.storePath isn't implementation/interface, it's a design question of whether we want to allow this kind of compromise to purity.

IMHO a setting (allow-impure-store-paths, defaulting to false) would be better.

[roberth]

Content addressed store paths are neither

• impure
• nor the result of impure derivations

I don't think we should further dilute the term.

How about something like allowed-store-path-dependencies, with possible values

• none
• content-addressed to allow CA paths (sources or floating outputs)
• built to allow the above and input addressed derivations
• impure to allow the above + impure derivations

Still not sure about -dependencies, have considered -literals. Maybe -values?

[peterwaller-arm]

Another potential user here. Pinging the thread since it has been a few months.

Click to expand use case (to avoid polluting the thread)

An immediate use I have of this is to put a copy of the nixpkgs sources into a machine image, which at the moment is quite painful. I feel I should be able to put `pkgs.path` into the `storePaths` of my image, but this results in an extra copy of the sources floating around at a strange path (`/nix/store/hash1-hash2-source`). `fetchClosure` doesn't quite work right currently as well; it makes a distinction between inputAddressed or not, and somehow the sources once copied to the image (and registered via a closureInfo registration and --load-db) end up incorrectly marked as inputAddressed [0]. I haven't come across a compelling argument there shouldn't be a straightforward way of getting a hold of this path if you want it.

[0] The consequence of which is that you can't write a fetchClosure expression which works both when built on the machine image built using it and on a machine that fetched the sources, since they differ in inputAddressed = true | false for the sources.

[roberth]

/nix/store/hash1-hash2-source

Technically that's hash1-<name>, but <name> is hash2-source, ie the basename of the store path you referenced.
This can be solved by using builtins.path { name = "source"; path = ./foo; } instead of ${./foo}.

In the case of pkgs.path, I'm not sure. It might make sense to revive NixOS/nixpkgs#153594, if the concerns raised there could be addressed. It should produce the same behavior, regardless of the method by which Nixpkgs is imported.
Alternatively, we are trying to eliminate copying operations where possible. Maybe we'll need a builtins.path-like function that returns a path value instead of a store path string - not sure.

EDIT: it's a large space of possible environments (in the store, not in the store)×(non-flakes, flakes), and solutions (path is a path value, path is a string, path is builtins.path something, path is the new alternative builtins.path-like function)