libexpr: derivationOf primop

[JustAGuyTryingHisBest]

Motivation

Taken directly from the related issue - This function improves RFC 92 and multi-derivation package support, by allowing the derivation path to be accessed for any output, whose derivations may be distinct, rather than only exposing a single drvPath.

Context

Resolves #10120

Translates solution from NixOS/nixpkgs#281536 to CppNix. Thank you to @roberth for the initial implementation.

---

Add 👍 to pull requests you find important.

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

[roberth]

This should reject nonsensical inputs, just like my Nixpkgs implementation would.

• 1 context item only
• start with storeDir (or CA placeholder, considering we haven't implemented ca-derivations input placeholder does not start with storeDir #12361)

Overly lenient functions produce garbage inputs to other functions, which then produce garbage errors, and we can't make functions less lenient without breaking user expressions, so this really has to be done with care and a bunch of "adversarial" tests.

[roberth]

Awesome. Could you make sure the returned string has the correct context?
Could you also add tests for "wrong" types?
I think we should also have an unrecoverable error for derivationOf ./..
What happens for a valid-looking store path without string context?
Or for CA placeholder paths? (Although we could just open an issue for the ca-derivations milestone for this one)

[JustAGuyTryingHisBest]

@roberth I appreciate your patience and working through this change with me!

Awesome. Could you make sure the returned string has the correct context?

Done. Does this seem like the right context?

Could you also add tests for "wrong" types?

Done. Do you see any additional tests that might be beneficial?

I think we should also have an unrecoverable error for derivationOf ./..

isStorePath handles most of the error handling for bad store paths

What happens for a valid-looking store path without string context?

see tests/functional/lang/eval-fail-derivationOf-no-context-store-path.err.exp

nix-repl> builtins.derivationOf "/nix/store/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-test"
error:
       … while calling the 'derivationOf' builtin
         at «string»:1:1:
            1| builtins.derivationOf "/nix/store/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-test"
             | ^

       error: '/nix/store/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-test' has no derivation in its context

Or for CA placeholder paths? (Although we could just open an issue for the ca-derivations milestone for this one)

I would opt to open an issue against the ca-derivation milestone.

[roberth]

Almost done :)

[roberth]

LGTM but has typo

Details

git apply this

diff --git a/tests/functional/lang/eval-okay-derivationOf-coerce.nix b/tests/functional/lang/eval-okay-derivationOf-coerce.nix
index 025157623..b00ca6fe3 100644
--- a/tests/functional/lang/eval-okay-derivationOf-coerce.nix
+++ b/tests/functional/lang/eval-okay-derivationOf-coerce.nix
@@ -5,4 +5,4 @@ let
     system = "x86_64-linux";
   };
 in
-builtins.derivationOf pkg.outPath == drv.drvPath
+builtins.derivationOf pkg.outPath == pkg.drvPath
diff --git a/tests/functional/lang/eval-okay-derivationOf.nix b/tests/functional/lang/eval-okay-derivationOf.nix
index 2abbac5c9..6386ee9a9 100644
--- a/tests/functional/lang/eval-okay-derivationOf.nix
+++ b/tests/functional/lang/eval-okay-derivationOf.nix
@@ -5,4 +5,4 @@ let
     system = "x86_64-linux";
   };
 in
-builtins.derivationOf pkg == drv.drvPath
+builtins.derivationOf pkg == pkg.drvPath

[Ericson2314]

See #15113. After that (or something like it) is merged, we can use EvalState::coerceToSingleDerivedPath in this function, which will make it much simpler.

[JustAGuyTryingHisBest]

See #15113. After that (or something like it) is merged, we can use EvalState::coerceToSingleDerivedPath in this function, which will make it much simpler.

Should I close this PR out or move it to a draft?

[Ericson2314]

Well I think I should go over the above plan with @roberth a bit, in case he disagrees and wants to go directly with this, so you don't have to draft it or close it.

[JustAGuyTryingHisBest]

Well I think I should go over the above plan with @roberth a bit, in case he disagrees and wants to go directly with this, so you don't have to draft it or close it.

Sounds like a plan. I appreciate your time and energy on this PR!