Create `outputOf` primop.
In the Nix language, given a drv path, we should be able to construct
another string referencing to one of its output. We can do this today
with `(import drvPath).output`, but this only works for derivations we
already have.
With dynamic derivations, however, that doesn't work well because the
`drvPath` isn't yet built: importing it like would need to trigger IFD,
when the whole point of this feature is to do "dynamic build graph"
without IFD!
Instead, what we want to do is create a placeholder value with the right
string context to refer to the output of the as-yet unbuilt derivation.
A new primop in the language, analogous to `builtins.placeholder` can be
used to create one. This will achieve all the right properties. The
placeholder machinery also will match out the `outPath` attribute for CA
derivations works.
In 60b7121d2c6d4322b7c2e8e7acfec7b701b2d3a1 we added that type of
placeholder, and the derived path and string holder changes necessary to
support it. Then in the previous commit we cleaned up the code
(inspiration finally hit me!) to deduplicate the code and expose exactly
what we need. Now, we can wire up the primop trivally!
Part of RFC 92: dynamic derivations (tracking issue #6316)
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-03-10 04:22:56 +00:00
|
|
|
#!/usr/bin/env bash
|
|
|
|
|
|
|
|
source ./common.sh
|
|
|
|
|
|
|
|
# Without the dynamic-derivations XP feature, we don't have the builtin.
|
|
|
|
nix --experimental-features 'nix-command' eval --impure --expr \
|
|
|
|
'assert ! (builtins ? outputOf); ""'
|
|
|
|
|
|
|
|
# Test that a string is required.
|
|
|
|
#
|
|
|
|
# We currently require a string to be passed, rather than a derivation
|
|
|
|
# object that could be coerced to a string. We might liberalise this in
|
|
|
|
# the future so it does work, but there are some design questions to
|
|
|
|
# resolve first. Adding a test so we don't liberalise it by accident.
|
|
|
|
expectStderr 1 nix --experimental-features 'nix-command dynamic-derivations' eval --impure --expr \
|
2023-08-23 12:00:00 +00:00
|
|
|
'builtins.outputOf (import ../dependencies.nix {}) "out"' \
|
2024-03-08 03:49:08 +00:00
|
|
|
| grepQuiet "expected a string but found a set"
|
Create `outputOf` primop.
In the Nix language, given a drv path, we should be able to construct
another string referencing to one of its output. We can do this today
with `(import drvPath).output`, but this only works for derivations we
already have.
With dynamic derivations, however, that doesn't work well because the
`drvPath` isn't yet built: importing it like would need to trigger IFD,
when the whole point of this feature is to do "dynamic build graph"
without IFD!
Instead, what we want to do is create a placeholder value with the right
string context to refer to the output of the as-yet unbuilt derivation.
A new primop in the language, analogous to `builtins.placeholder` can be
used to create one. This will achieve all the right properties. The
placeholder machinery also will match out the `outPath` attribute for CA
derivations works.
In 60b7121d2c6d4322b7c2e8e7acfec7b701b2d3a1 we added that type of
placeholder, and the derived path and string holder changes necessary to
support it. Then in the previous commit we cleaned up the code
(inspiration finally hit me!) to deduplicate the code and expose exactly
what we need. Now, we can wire up the primop trivally!
Part of RFC 92: dynamic derivations (tracking issue #6316)
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-03-10 04:22:56 +00:00
|
|
|
|
|
|
|
# Test that "DrvDeep" string contexts are not supported at this time
|
|
|
|
#
|
|
|
|
# Like the above, this is a restriction we could relax later.
|
|
|
|
expectStderr 1 nix --experimental-features 'nix-command dynamic-derivations' eval --impure --expr \
|
2023-08-23 12:00:00 +00:00
|
|
|
'builtins.outputOf (import ../dependencies.nix {}).drvPath "out"' \
|
Create `outputOf` primop.
In the Nix language, given a drv path, we should be able to construct
another string referencing to one of its output. We can do this today
with `(import drvPath).output`, but this only works for derivations we
already have.
With dynamic derivations, however, that doesn't work well because the
`drvPath` isn't yet built: importing it like would need to trigger IFD,
when the whole point of this feature is to do "dynamic build graph"
without IFD!
Instead, what we want to do is create a placeholder value with the right
string context to refer to the output of the as-yet unbuilt derivation.
A new primop in the language, analogous to `builtins.placeholder` can be
used to create one. This will achieve all the right properties. The
placeholder machinery also will match out the `outPath` attribute for CA
derivations works.
In 60b7121d2c6d4322b7c2e8e7acfec7b701b2d3a1 we added that type of
placeholder, and the derived path and string holder changes necessary to
support it. Then in the previous commit we cleaned up the code
(inspiration finally hit me!) to deduplicate the code and expose exactly
what we need. Now, we can wire up the primop trivally!
Part of RFC 92: dynamic derivations (tracking issue #6316)
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-03-10 04:22:56 +00:00
|
|
|
| grepQuiet "has a context which refers to a complete source and binary closure. This is not supported at this time"
|
|
|
|
|
|
|
|
# Test using `builtins.outputOf` with static derivations
|
|
|
|
testStaticHello () {
|
|
|
|
nix eval --impure --expr \
|
|
|
|
'with (import ./text-hashed-output.nix); let
|
|
|
|
a = hello.outPath;
|
|
|
|
b = builtins.outputOf (builtins.unsafeDiscardOutputDependency hello.drvPath) "out";
|
|
|
|
in builtins.trace a
|
|
|
|
(builtins.trace b
|
|
|
|
(assert a == b; null))'
|
|
|
|
}
|
|
|
|
|
|
|
|
# Test with a regular old input-addresed derivation
|
|
|
|
#
|
|
|
|
# `builtins.outputOf` works without ca-derivations and doesn't create a
|
|
|
|
# placeholder but just returns the output path.
|
|
|
|
testStaticHello
|
|
|
|
|
|
|
|
# Test with content addressed derivation.
|
|
|
|
NIX_TESTS_CA_BY_DEFAULT=1 testStaticHello
|
|
|
|
|
|
|
|
# Test with derivation-producing derivation
|
|
|
|
#
|
|
|
|
# This is hardly different from the preceding cases, except that we're
|
|
|
|
# only taking 1 outputOf out of 2 possible outputOfs. Note that
|
|
|
|
# `.outPath` could be defined as `outputOf drvPath`, which is what we're
|
|
|
|
# testing here. The other `outputOf` that we're not testing here is the
|
|
|
|
# use of _dynamic_ derivations.
|
|
|
|
nix eval --impure --expr \
|
|
|
|
'with (import ./text-hashed-output.nix); let
|
|
|
|
a = producingDrv.outPath;
|
|
|
|
b = builtins.outputOf (builtins.builtins.unsafeDiscardOutputDependency producingDrv.drvPath) "out";
|
|
|
|
in builtins.trace a
|
|
|
|
(builtins.trace b
|
|
|
|
(assert a == b; null))'
|
|
|
|
|
|
|
|
# Test with unbuilt output of derivation-producing derivation.
|
|
|
|
#
|
|
|
|
# This function similar to `testStaticHello` used above, but instead of
|
|
|
|
# checking the property on a constant derivation, we check it on a
|
|
|
|
# derivation that's from another derivation's output (outPath).
|
|
|
|
testDynamicHello () {
|
|
|
|
nix eval --impure --expr \
|
|
|
|
'with (import ./text-hashed-output.nix); let
|
|
|
|
a = builtins.outputOf producingDrv.outPath "out";
|
|
|
|
b = builtins.outputOf (builtins.outputOf (builtins.unsafeDiscardOutputDependency producingDrv.drvPath) "out") "out";
|
|
|
|
in builtins.trace a
|
|
|
|
(builtins.trace b
|
|
|
|
(assert a == b; null))'
|
|
|
|
}
|
|
|
|
|
|
|
|
# inner dynamic derivation is input-addressed
|
|
|
|
testDynamicHello
|
|
|
|
|
|
|
|
# inner dynamic derivation is content-addressed
|
|
|
|
NIX_TESTS_CA_BY_DEFAULT=1 testDynamicHello
|