2023-07-10 02:24:51 +00:00
|
|
|
dyn-drv-tests := \
|
|
|
|
|
$(d)/text-hashed-output.sh \
|
Make the Derived Path family of types inductive for dynamic derivations
We want to be able to write down `foo.drv^bar.drv^baz`:
`foo.drv^bar.drv` is the dynamic derivation (since it is itself a
derivation output, `bar.drv` from `foo.drv`).
To that end, we create `Single{Derivation,BuiltPath}` types, that are
very similar except instead of having multiple outputs (in a set or
map), they have a single one. This is for everything to the left of the
rightmost `^`.
`NixStringContextElem` has an analogous change, and now can reuse
`SingleDerivedPath` at the top level. In fact, if we ever get rid of
`DrvDeep`, `NixStringContextElem` could be replaced with
`SingleDerivedPath` entirely!
Important note: some JSON formats have changed.
We already can *produce* dynamic derivations, but we can't refer to them
directly. Today, we can merely express building or example at the top
imperatively over time by building `foo.drv^bar.drv`, and then with a
second nix invocation doing `<result-from-first>^baz`, but this is not
declarative. The ethos of Nix of being able to write down the full plan
everything you want to do, and then execute than plan with a single
command, and for that we need the new inductive form of these types.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
2023-01-15 22:39:04 +00:00
|
|
|
$(d)/recursive-mod-json.sh \
|
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
|
|
|
$(d)/build-built-drv.sh \
|
|
|
|
|
$(d)/eval-outputOf.sh \
|
2023-09-07 02:57:37 +00:00
|
|
|
$(d)/dep-built-drv.sh \
|
|
|
|
|
$(d)/old-daemon-error-hack.sh
|
2023-07-10 02:24:51 +00:00
|
|
|
|
|
|
|
|
install-tests-groups += dyn-drv
|
|
|
|
|
|
|
|
|
|
clean-files += \
|
|
|
|
|
$(d)/config.nix
|
|
|
|
|
|
|
|
|
|
test-deps += \
|
2023-10-05 16:12:18 +00:00
|
|
|
tests/functional/dyn-drv/config.nix
|