Introduce nix instantiate

[layus]

This is similar to nix-instantiate with support for installables (and flakes).

Motivation

The ability to obtain a derivation with the new cli has never been really implemented. #3908 (comment) is the best work-around, but it does not add a gc root for the generated paths.

This brings a dedicated entry-point with the right semantics instead of the workaround above.

Context

Fixes #3908

To some extent, this also addresses #7138 because outputs can easily be rooted. This brings that capability to store derivations.

Priorities and Process

Add 👍 to pull requests you find important.

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

[Mic92]

Looks overall like a clean subset of nix-instantiate.
However some integration test would be nice and should be easy to add (with and without JSON).

[fgaz]

I think instantiate should not be placed under the derivation namespace. As I see it, derivation commands should operate on derivations and should not have to know about expressions/flakes/installables. This command however operates on installables to produce a derivation.

See also #7868 and #7903, cc @Ericson2314

[layus]

@fgaz All right, but where then ?

[layus]

The best place I can think of right now is nix build --derivation. But one may prefer nix instantiate. This is a trivial change, but how to get an agreement ? Should I organize a poll ?

[fgaz]

The best place I can think of right now is nix build --derivation. But one may prefer nix instantiate.

Both look fine to me. Another option is nix eval --derivation (eval instantiates the derivation from the expression anyway, it just isn't able to print it because .drvPath is an implementation detail).

This is a trivial change, but how to get an agreement ? Should I organize a poll ?

I think for now we can just wait for a nix maintainer to give their opinion.

[edolstra]

I think nix derivation instantiate is preferable since we don't want to pollute the top-level namespace with a utility command like this. Also, maybe it should be nix derivation create to avoid the "instantiate" terminology from the old CLI. (Or nix derivation add, but that one is already taken. It should really have been called nix derivation import.)

BTW, the reason that the new CLI doesn't have an equivalent for nix-instantiate is because ideally we would get rid of store derivations in the future. The Nix client should just send an in-memory representation of derivations to the daemon, without the need to materialize them on disk. So the fewer places where we expose .drvs in the new CLI, the better.

[roberth]

So the fewer places where we expose .drvs in the new CLI, the better.

We're already doing a good job at this, but in this new scenario, we'll still need the functionality of writing .drvs somewhere not in memory, for analysis by other tools, such as nix-diff. While all other commands could skip the instantiation into the actual store, this command could be used to do it anyway.
Alternatively or in addition, this functionality could be added to all commands by means of a flag, such as --instantiate and/or --instantiation-store.
Before any of that, we have to be sure whether instantiation means the act of computing the derivations (hashing them, etc), which is quite independent of evaluating the derivation arguments, especially when we have hash placeholder string thunks, or whether it is the act of writing them out in a somewhat user facing way.
Or do we define instantiation as computing the derivation of the outPath to further diminish the role of actual drv files? That is in contrast to nix eval which does not care about derivations and outputs any more than the language itself does.
(I assumed #6507; s/outPath/drvPath/ otherwise.)