2023-02-05 19:16:17 +02:00
|
|
|
#include "installable-value.hh"
|
|
|
|
#include "eval-cache.hh"
|
|
|
|
|
|
|
|
namespace nix {
|
|
|
|
|
|
|
|
std::vector<ref<eval_cache::AttrCursor>>
|
|
|
|
InstallableValue::getCursors(EvalState & state)
|
|
|
|
{
|
|
|
|
auto evalCache =
|
|
|
|
std::make_shared<nix::eval_cache::EvalCache>(std::nullopt, state,
|
|
|
|
[&]() { return toValue(state).first; });
|
|
|
|
return {evalCache->getRoot()};
|
|
|
|
}
|
|
|
|
|
|
|
|
ref<eval_cache::AttrCursor>
|
|
|
|
InstallableValue::getCursor(EvalState & state)
|
|
|
|
{
|
|
|
|
/* Although getCursors should return at least one element, in case it doesn't,
|
|
|
|
bound check to avoid an undefined behavior for vector[0] */
|
|
|
|
return getCursors(state).at(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static UsageError nonValueInstallable(Installable & installable)
|
|
|
|
{
|
2023-04-07 16:55:28 +03:00
|
|
|
return UsageError("installable '%s' does not correspond to a Nix language value", installable.what());
|
2023-02-05 19:16:17 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
InstallableValue & InstallableValue::require(Installable & installable)
|
|
|
|
{
|
|
|
|
auto * castedInstallable = dynamic_cast<InstallableValue *>(&installable);
|
|
|
|
if (!castedInstallable)
|
|
|
|
throw nonValueInstallable(installable);
|
|
|
|
return *castedInstallable;
|
|
|
|
}
|
|
|
|
|
|
|
|
ref<InstallableValue> InstallableValue::require(ref<Installable> installable)
|
|
|
|
{
|
|
|
|
auto castedInstallable = installable.dynamic_pointer_cast<InstallableValue>();
|
|
|
|
if (!castedInstallable)
|
|
|
|
throw nonValueInstallable(*installable);
|
|
|
|
return ref { castedInstallable };
|
|
|
|
}
|
|
|
|
|
Make more string values work as installables
As discussed in #7417, it would be good to make more string values work
as installables. That is to say, if an installable refers to a value,
and the value is a string, it used to not work at all, since #7484, it
works somewhat, and this PR make it work some more.
The new cases that are added for `BuiltPath` contexts:
- Fixed input- or content-addressed derivation:
```
nix-repl> hello.out.outPath
"/nix/store/jppfl2bp1zhx8sgs2mgifmsx6dv16mv2-hello-2.12"
nix-repl> :p builtins.getContext hello.out.outPath
{ "/nix/store/c7jrxqjhdda93lhbkanqfs07x2bzazbm-hello-2.12.drv" = { outputs = [ "out" ]; }; }
The string matches the specified single output of that derivation, so
it should also be valid.
- Floating content-addressed derivation:
```
nix-repl> (hello.overrideAttrs (_: { __contentAddressed = true; })).out.outPath
"/1a08j26xqc0zm8agps8anxpjji410yvsx4pcgyn4bfan1ddkx2g0"
nix-repl> :p builtins.getContext (hello.overrideAttrs (_: { __contentAddressed = true; })).out.outPath
{ "/nix/store/qc645pyf9wl37c6qvqzaqkwsm1gp48al-hello-2.12.drv" = { outputs = [ "out" ]; }; }
```
The string is not a path but a placeholder, however it also matches
the context, and because it is a CA derivation we have no better
option. This should also be valid.
We may also want to think about richer attrset based values (also
discussed in that issue and #6507), but this change "completes" our
string-based building blocks, from which the others can be desugared
into or at least described/document/taught in terms of.
Progress towards #7417
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2023-01-11 00:18:59 +02:00
|
|
|
std::optional<DerivedPathWithInfo> InstallableValue::trySinglePathToDerivedPaths(Value & v, const PosIdx pos, std::string_view errorCtx)
|
|
|
|
{
|
|
|
|
if (v.type() == nPath) {
|
|
|
|
auto storePath = v.path().fetchToStore(state->store);
|
|
|
|
return {{
|
|
|
|
.path = DerivedPath::Opaque {
|
|
|
|
.path = std::move(storePath),
|
|
|
|
},
|
|
|
|
.info = make_ref<ExtraPathInfo>(),
|
|
|
|
}};
|
|
|
|
}
|
|
|
|
|
|
|
|
else if (v.type() == nString) {
|
|
|
|
return {{
|
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-16 00:39:04 +02:00
|
|
|
.path = DerivedPath::fromSingle(
|
|
|
|
state->coerceToSingleDerivedPath(pos, v, errorCtx)),
|
Make more string values work as installables
As discussed in #7417, it would be good to make more string values work
as installables. That is to say, if an installable refers to a value,
and the value is a string, it used to not work at all, since #7484, it
works somewhat, and this PR make it work some more.
The new cases that are added for `BuiltPath` contexts:
- Fixed input- or content-addressed derivation:
```
nix-repl> hello.out.outPath
"/nix/store/jppfl2bp1zhx8sgs2mgifmsx6dv16mv2-hello-2.12"
nix-repl> :p builtins.getContext hello.out.outPath
{ "/nix/store/c7jrxqjhdda93lhbkanqfs07x2bzazbm-hello-2.12.drv" = { outputs = [ "out" ]; }; }
The string matches the specified single output of that derivation, so
it should also be valid.
- Floating content-addressed derivation:
```
nix-repl> (hello.overrideAttrs (_: { __contentAddressed = true; })).out.outPath
"/1a08j26xqc0zm8agps8anxpjji410yvsx4pcgyn4bfan1ddkx2g0"
nix-repl> :p builtins.getContext (hello.overrideAttrs (_: { __contentAddressed = true; })).out.outPath
{ "/nix/store/qc645pyf9wl37c6qvqzaqkwsm1gp48al-hello-2.12.drv" = { outputs = [ "out" ]; }; }
```
The string is not a path but a placeholder, however it also matches
the context, and because it is a CA derivation we have no better
option. This should also be valid.
We may also want to think about richer attrset based values (also
discussed in that issue and #6507), but this change "completes" our
string-based building blocks, from which the others can be desugared
into or at least described/document/taught in terms of.
Progress towards #7417
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2023-01-11 00:18:59 +02:00
|
|
|
.info = make_ref<ExtraPathInfo>(),
|
|
|
|
}};
|
|
|
|
}
|
|
|
|
|
|
|
|
else return std::nullopt;
|
|
|
|
}
|
|
|
|
|
2023-02-05 19:16:17 +02:00
|
|
|
}
|