2023-01-23 01:00:26 +03:00
|
|
|
//! Implements `builtins.derivation`, the core of what makes Nix build packages.
|
2023-11-03 16:40:32 +02:00
|
|
|
use crate::builtins::DerivationError;
|
2023-12-26 02:03:05 +01:00
|
|
|
use crate::known_paths::KnownPaths;
|
feat(tvix/glue/derivationStrict): support __structuredAttrs
This adds support to handle the __structuredAttrs argument, which can be
passed to builtins.derivationStrict.
If __structuredAttrs is passed, and set to true, most of the arguments
passed to builtins.derivationStrict are not simply coerced to a string
and passed down to "environments", but instead kept in a more structured
fashion.
Inside ATerm, which is what's relevant as far as path calculation is
concerned, a virtual `__json` environment variable is present,
containing these structured values.
Inside Builds, these structured values are not made available as an
environment variable, but a JSON file (and source-able bash script).
This will need to be respected once we start emitting BuildRequests,
and for that we can probably just parse the `__json` key in
Derivation.environment again - or keep this additionally in
non-serialized form around during Evaluation.
No matter what, this is left for a followup CL.
The existing handle_derivation_parameters and populate_outputs helper
function were removed, as __structuredAttrs causes quite a change
in behaviour, and so handling both in the same place makes it more
readable.
There's some open questions w.r.t. string contexts for structured attrs
itself. A TODO is left for this, but at least path calculation for
individual structured attrs derivations are correct now.
Part of b/366.
Change-Id: Ic293822266ced6f8c4826d8ef0d2e098a4adccaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10604
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2024-01-11 15:44:31 +02:00
|
|
|
use bstr::BString;
|
2023-10-22 22:24:33 +01:00
|
|
|
use nix_compat::derivation::{Derivation, Output};
|
2023-03-30 14:01:38 +02:00
|
|
|
use nix_compat::nixhash;
|
2023-01-23 01:44:24 +03:00
|
|
|
use std::cell::RefCell;
|
2023-01-23 01:12:59 +03:00
|
|
|
use std::collections::{btree_map, BTreeSet};
|
2023-01-23 01:44:24 +03:00
|
|
|
use std::rc::Rc;
|
|
|
|
use tvix_eval::builtin_macros::builtins;
|
2023-06-01 21:21:23 +02:00
|
|
|
use tvix_eval::generators::{self, emit_warning_kind, GenCo};
|
2023-09-09 22:02:56 -07:00
|
|
|
use tvix_eval::{
|
2023-12-26 02:03:05 +01:00
|
|
|
AddContext, CatchableErrorKind, CoercionKind, ErrorKind, NixAttrs, NixContext,
|
feat(tvix/glue/derivationStrict): support __structuredAttrs
This adds support to handle the __structuredAttrs argument, which can be
passed to builtins.derivationStrict.
If __structuredAttrs is passed, and set to true, most of the arguments
passed to builtins.derivationStrict are not simply coerced to a string
and passed down to "environments", but instead kept in a more structured
fashion.
Inside ATerm, which is what's relevant as far as path calculation is
concerned, a virtual `__json` environment variable is present,
containing these structured values.
Inside Builds, these structured values are not made available as an
environment variable, but a JSON file (and source-able bash script).
This will need to be respected once we start emitting BuildRequests,
and for that we can probably just parse the `__json` key in
Derivation.environment again - or keep this additionally in
non-serialized form around during Evaluation.
No matter what, this is left for a followup CL.
The existing handle_derivation_parameters and populate_outputs helper
function were removed, as __structuredAttrs causes quite a change
in behaviour, and so handling both in the same place makes it more
readable.
There's some open questions w.r.t. string contexts for structured attrs
itself. A TODO is left for this, but at least path calculation for
individual structured attrs derivations are correct now.
Part of b/366.
Change-Id: Ic293822266ced6f8c4826d8ef0d2e098a4adccaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10604
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2024-01-11 15:44:31 +02:00
|
|
|
NixContextElement, Value, WarningKind,
|
2023-09-09 22:02:56 -07:00
|
|
|
};
|
2023-01-23 01:00:26 +03:00
|
|
|
|
2023-01-23 01:38:36 +03:00
|
|
|
// Constants used for strangely named fields in derivation inputs.
|
2023-01-23 01:44:24 +03:00
|
|
|
const STRUCTURED_ATTRS: &str = "__structuredAttrs";
|
2023-01-23 01:38:36 +03:00
|
|
|
const IGNORE_NULLS: &str = "__ignoreNulls";
|
|
|
|
|
2023-01-23 01:12:59 +03:00
|
|
|
/// Populate the inputs of a derivation from the build references
|
2023-12-26 02:03:05 +01:00
|
|
|
/// found when scanning the derivation's parameters and extracting their contexts.
|
|
|
|
fn populate_inputs(drv: &mut Derivation, full_context: NixContext) {
|
|
|
|
for element in full_context.iter() {
|
|
|
|
match element {
|
|
|
|
NixContextElement::Plain(source) => {
|
|
|
|
drv.input_sources.insert(source.clone());
|
2023-01-23 01:12:59 +03:00
|
|
|
}
|
|
|
|
|
2023-12-26 02:03:05 +01:00
|
|
|
NixContextElement::Single { name, derivation } => {
|
2023-01-23 01:12:59 +03:00
|
|
|
match drv.input_derivations.entry(derivation.clone()) {
|
|
|
|
btree_map::Entry::Vacant(entry) => {
|
|
|
|
entry.insert(BTreeSet::from([name.clone()]));
|
|
|
|
}
|
|
|
|
|
|
|
|
btree_map::Entry::Occupied(mut entry) => {
|
|
|
|
entry.get_mut().insert(name.clone());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-12-26 02:03:05 +01:00
|
|
|
NixContextElement::Derivation(_drv_path) => {
|
|
|
|
// This is a hard one, it means that
|
|
|
|
// we are depending on a drvPath of ourselves
|
|
|
|
// *or* another derivation's drvPath.
|
|
|
|
// What to do here?
|
|
|
|
panic!("please do not depend on drvPath, I have 2 hours of sleep in blood");
|
2023-01-23 01:12:59 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-01-30 22:43:55 +01:00
|
|
|
/// Populate the output configuration of a derivation based on the
|
2023-10-22 22:24:33 +01:00
|
|
|
/// parameters passed to the call, configuring a fixed-output derivation output
|
|
|
|
/// if necessary.
|
2023-01-30 22:43:55 +01:00
|
|
|
///
|
|
|
|
/// This function handles all possible combinations of the
|
|
|
|
/// parameters, including invalid ones.
|
|
|
|
///
|
fix(tvix/cli): handle SRI hashes in outputHash
Instead of being called with `md5`, `sha1`, `sha256` or `sha512`,
`fetchurl.nix` (from corepkgs / `<nix`) can also be called with a `hash`
attribute, being an SRI hash.
In that case, `builtin.derivation` is called with `outputHashAlgo` being
an empty string, and `outputHash` being an SRI hash string.
In other cases, an SRI hash is passed as outputHash, but outputHashAlgo
is set too.
Nix does modify these values in (single, fixed) output specification it
serializes to ATerm, but keeps it unharmed in `env`.
Move this into a construct_output_hash helper function, that can be
tested better in isolation.
Change-Id: Id9d716a119664c44ea7747540399966752e20187
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7933
Reviewed-by: tazjin <tazjin@tvl.su>
Autosubmit: flokli <flokli@flokli.de>
Tested-by: BuildkiteCI
2023-01-26 14:18:12 +01:00
|
|
|
/// Due to the support for SRI hashes, and how these are passed along to
|
|
|
|
/// builtins.derivation, outputHash and outputHashAlgo can have values which
|
|
|
|
/// need to be further modified before constructing the Derivation struct.
|
|
|
|
///
|
|
|
|
/// If outputHashAlgo is an SRI hash, outputHashAlgo must either be an empty
|
|
|
|
/// string, or the hash algorithm as specified in the (single) SRI (entry).
|
|
|
|
/// SRI strings with multiple hash algorithms are not supported.
|
|
|
|
///
|
|
|
|
/// In case an SRI string was used, the (single) fixed output is populated
|
|
|
|
/// with the hash algo name, and the hash digest is populated with the
|
|
|
|
/// (lowercase) hex encoding of the digest.
|
|
|
|
///
|
|
|
|
/// These values are only rewritten for the outputs, not what's passed to env.
|
2023-12-30 03:01:59 +01:00
|
|
|
///
|
|
|
|
/// The return value may optionally contain a warning.
|
2023-10-22 22:24:33 +01:00
|
|
|
fn handle_fixed_output(
|
2023-01-23 01:28:27 +03:00
|
|
|
drv: &mut Derivation,
|
2023-10-22 22:24:33 +01:00
|
|
|
hash_str: Option<String>, // in nix: outputHash
|
|
|
|
hash_algo_str: Option<String>, // in nix: outputHashAlgo
|
|
|
|
hash_mode_str: Option<String>, // in nix: outputHashmode
|
2023-12-30 03:01:59 +01:00
|
|
|
) -> Result<Option<WarningKind>, ErrorKind> {
|
2023-10-22 22:24:33 +01:00
|
|
|
// If outputHash is provided, ensure hash_algo_str is compatible.
|
|
|
|
// If outputHash is not provided, do nothing.
|
|
|
|
if let Some(hash_str) = hash_str {
|
|
|
|
// treat an empty algo as None
|
|
|
|
let hash_algo_str = match hash_algo_str {
|
|
|
|
Some(s) if s.is_empty() => None,
|
|
|
|
Some(s) => Some(s),
|
|
|
|
None => None,
|
|
|
|
};
|
2023-01-23 01:28:27 +03:00
|
|
|
|
2023-10-22 22:24:33 +01:00
|
|
|
// construct a NixHash.
|
|
|
|
let nixhash = nixhash::from_str(&hash_str, hash_algo_str.as_deref())
|
2023-11-03 16:40:32 +02:00
|
|
|
.map_err(DerivationError::InvalidOutputHash)?;
|
2023-12-30 03:01:59 +01:00
|
|
|
let algo = nixhash.algo();
|
2023-10-22 22:24:33 +01:00
|
|
|
|
|
|
|
// construct the fixed output.
|
|
|
|
drv.outputs.insert(
|
|
|
|
"out".to_string(),
|
|
|
|
Output {
|
|
|
|
path: "".to_string(),
|
|
|
|
ca_hash: match hash_mode_str.as_deref() {
|
|
|
|
None | Some("flat") => Some(nixhash::CAHash::Flat(nixhash)),
|
|
|
|
Some("recursive") => Some(nixhash::CAHash::Nar(nixhash)),
|
2023-11-03 16:40:32 +02:00
|
|
|
Some(other) => {
|
|
|
|
return Err(DerivationError::InvalidOutputHashMode(other.to_string()))?
|
|
|
|
}
|
2023-10-22 22:24:33 +01:00
|
|
|
},
|
|
|
|
},
|
|
|
|
);
|
2023-12-30 03:01:59 +01:00
|
|
|
|
|
|
|
// Peek at hash_str once more.
|
|
|
|
// If it was a SRI hash, but is not using the correct length, this means
|
|
|
|
// the padding was wrong. Emit a warning in that case.
|
|
|
|
let sri_prefix = format!("{}-", algo);
|
|
|
|
if let Some(rest) = hash_str.strip_prefix(&sri_prefix) {
|
|
|
|
if data_encoding::BASE64.encode_len(algo.digest_length()) != rest.len() {
|
|
|
|
return Ok(Some(WarningKind::SRIHashWrongPadding));
|
|
|
|
}
|
|
|
|
}
|
2023-10-22 22:24:33 +01:00
|
|
|
}
|
2023-12-30 03:01:59 +01:00
|
|
|
Ok(None)
|
2023-01-23 01:28:27 +03:00
|
|
|
}
|
|
|
|
|
2023-01-23 01:44:24 +03:00
|
|
|
#[builtins(state = "Rc<RefCell<KnownPaths>>")]
|
2023-11-03 16:40:32 +02:00
|
|
|
pub(crate) mod derivation_builtins {
|
feat(tvix/glue/derivationStrict): support __structuredAttrs
This adds support to handle the __structuredAttrs argument, which can be
passed to builtins.derivationStrict.
If __structuredAttrs is passed, and set to true, most of the arguments
passed to builtins.derivationStrict are not simply coerced to a string
and passed down to "environments", but instead kept in a more structured
fashion.
Inside ATerm, which is what's relevant as far as path calculation is
concerned, a virtual `__json` environment variable is present,
containing these structured values.
Inside Builds, these structured values are not made available as an
environment variable, but a JSON file (and source-able bash script).
This will need to be respected once we start emitting BuildRequests,
and for that we can probably just parse the `__json` key in
Derivation.environment again - or keep this additionally in
non-serialized form around during Evaluation.
No matter what, this is left for a followup CL.
The existing handle_derivation_parameters and populate_outputs helper
function were removed, as __structuredAttrs causes quite a change
in behaviour, and so handling both in the same place makes it more
readable.
There's some open questions w.r.t. string contexts for structured attrs
itself. A TODO is left for this, but at least path calculation for
individual structured attrs derivations are correct now.
Part of b/366.
Change-Id: Ic293822266ced6f8c4826d8ef0d2e098a4adccaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10604
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2024-01-11 15:44:31 +02:00
|
|
|
use std::collections::BTreeMap;
|
|
|
|
|
2023-01-23 01:44:24 +03:00
|
|
|
use super::*;
|
2023-03-30 14:01:38 +02:00
|
|
|
use nix_compat::store_path::hash_placeholder;
|
refactor(tvix/eval): flatten call stack of VM using generators
Warning: This is probably the biggest refactor in tvix-eval history,
so far.
This replaces all instances of trampolines and recursion during
evaluation of the VM loop with generators. A generator is an
asynchronous function that can be suspended to yield a message (in our
case, vm::generators::GeneratorRequest) and receive a
response (vm::generators::GeneratorResponsee).
The `genawaiter` crate provides an interpreter for generators that can
drive their execution and lets us move control flow between the VM and
suspended generators.
To do this, massive changes have occured basically everywhere in the
code. On a high-level:
1. The VM is now organised around a frame stack. A frame is either a
call frame (execution of Tvix bytecode) or a generator frame (a
running or suspended generator).
The VM has an outer loop that pops a frame off the frame stack, and
then enters an inner loop either driving the execution of the
bytecode or the execution of a generator.
Both types of frames have several branches that can result in the
frame re-enqueuing itself, and enqueuing some other work (in the
form of a different frame) on top of itself. The VM will eventually
resume the frame when everything "above" it has been suspended.
In this way, the VM's new frame stack takes over much of the work
that was previously achieved by recursion.
2. All methods previously taking a VM have been refactored into async
functions that instead emit/receive generator messages for
communication with the VM.
Notably, this includes *all* builtins.
This has had some other effects:
- Some test have been removed or commented out, either because they
tested code that was mostly already dead (nix_eq) or because they
now require generator scaffolding which we do not have in place for
tests (yet).
- Because generator functions are technically async (though no async
IO is involved), we lose the ability to use much of the Rust
standard library e.g. in builtins. This has led to many algorithms
being unrolled into iterative versions instead of iterator
combinations, and things like sorting had to be implemented from scratch.
- Many call sites that previously saw a `Result<..., ErrorKind>`
bubble up now only see the result value, as the error handling is
encapsulated within the generator loop.
This reduces number of places inside of builtin implementations
where error context can be attached to calls that can fail.
Currently what we gain in this tradeoff is significantly more
detailed span information (which we still need to bubble up, this
commit does not change the error display).
We'll need to do some analysis later of how useful the errors turn
out to be and potentially introduce some methods for attaching
context to a generator frame again.
This change is very difficult to do in stages, as it is very much an
"all or nothing" change that affects huge parts of the codebase. I've
tried to isolate changes that can be isolated into the parent CLs of
this one, but this change is still quite difficult to wrap one's mind
and I'm available to discuss it and explain things to any reviewer.
Fixes: b/238, b/237, b/251 and potentially others.
Change-Id: I39244163ff5bbecd169fe7b274df19262b515699
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8104
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
Reviewed-by: Adam Joseph <adam@westernsemico.com>
Tested-by: BuildkiteCI
2023-02-14 15:02:39 +03:00
|
|
|
use tvix_eval::generators::Gen;
|
2023-12-26 02:03:05 +01:00
|
|
|
use tvix_eval::{NixContext, NixContextElement, NixString};
|
2023-01-23 01:44:24 +03:00
|
|
|
|
2023-01-31 19:43:33 +03:00
|
|
|
#[builtin("placeholder")]
|
refactor(tvix/eval): flatten call stack of VM using generators
Warning: This is probably the biggest refactor in tvix-eval history,
so far.
This replaces all instances of trampolines and recursion during
evaluation of the VM loop with generators. A generator is an
asynchronous function that can be suspended to yield a message (in our
case, vm::generators::GeneratorRequest) and receive a
response (vm::generators::GeneratorResponsee).
The `genawaiter` crate provides an interpreter for generators that can
drive their execution and lets us move control flow between the VM and
suspended generators.
To do this, massive changes have occured basically everywhere in the
code. On a high-level:
1. The VM is now organised around a frame stack. A frame is either a
call frame (execution of Tvix bytecode) or a generator frame (a
running or suspended generator).
The VM has an outer loop that pops a frame off the frame stack, and
then enters an inner loop either driving the execution of the
bytecode or the execution of a generator.
Both types of frames have several branches that can result in the
frame re-enqueuing itself, and enqueuing some other work (in the
form of a different frame) on top of itself. The VM will eventually
resume the frame when everything "above" it has been suspended.
In this way, the VM's new frame stack takes over much of the work
that was previously achieved by recursion.
2. All methods previously taking a VM have been refactored into async
functions that instead emit/receive generator messages for
communication with the VM.
Notably, this includes *all* builtins.
This has had some other effects:
- Some test have been removed or commented out, either because they
tested code that was mostly already dead (nix_eq) or because they
now require generator scaffolding which we do not have in place for
tests (yet).
- Because generator functions are technically async (though no async
IO is involved), we lose the ability to use much of the Rust
standard library e.g. in builtins. This has led to many algorithms
being unrolled into iterative versions instead of iterator
combinations, and things like sorting had to be implemented from scratch.
- Many call sites that previously saw a `Result<..., ErrorKind>`
bubble up now only see the result value, as the error handling is
encapsulated within the generator loop.
This reduces number of places inside of builtin implementations
where error context can be attached to calls that can fail.
Currently what we gain in this tradeoff is significantly more
detailed span information (which we still need to bubble up, this
commit does not change the error display).
We'll need to do some analysis later of how useful the errors turn
out to be and potentially introduce some methods for attaching
context to a generator frame again.
This change is very difficult to do in stages, as it is very much an
"all or nothing" change that affects huge parts of the codebase. I've
tried to isolate changes that can be isolated into the parent CLs of
this one, but this change is still quite difficult to wrap one's mind
and I'm available to discuss it and explain things to any reviewer.
Fixes: b/238, b/237, b/251 and potentially others.
Change-Id: I39244163ff5bbecd169fe7b274df19262b515699
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8104
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
Reviewed-by: Adam Joseph <adam@westernsemico.com>
Tested-by: BuildkiteCI
2023-02-14 15:02:39 +03:00
|
|
|
async fn builtin_placeholder(co: GenCo, input: Value) -> Result<Value, ErrorKind> {
|
2023-12-30 03:21:45 +01:00
|
|
|
if input.is_catchable() {
|
|
|
|
return Ok(input);
|
|
|
|
}
|
|
|
|
|
2023-01-31 19:43:33 +03:00
|
|
|
let placeholder = hash_placeholder(
|
|
|
|
input
|
|
|
|
.to_str()
|
|
|
|
.context("looking at output name in builtins.placeholder")?
|
|
|
|
.as_str(),
|
|
|
|
);
|
|
|
|
|
|
|
|
Ok(placeholder.into())
|
|
|
|
}
|
|
|
|
|
2023-01-23 01:44:24 +03:00
|
|
|
/// Strictly construct a Nix derivation from the supplied arguments.
|
|
|
|
///
|
|
|
|
/// This is considered an internal function, users usually want to
|
|
|
|
/// use the higher-level `builtins.derivation` instead.
|
|
|
|
#[builtin("derivationStrict")]
|
refactor(tvix/eval): flatten call stack of VM using generators
Warning: This is probably the biggest refactor in tvix-eval history,
so far.
This replaces all instances of trampolines and recursion during
evaluation of the VM loop with generators. A generator is an
asynchronous function that can be suspended to yield a message (in our
case, vm::generators::GeneratorRequest) and receive a
response (vm::generators::GeneratorResponsee).
The `genawaiter` crate provides an interpreter for generators that can
drive their execution and lets us move control flow between the VM and
suspended generators.
To do this, massive changes have occured basically everywhere in the
code. On a high-level:
1. The VM is now organised around a frame stack. A frame is either a
call frame (execution of Tvix bytecode) or a generator frame (a
running or suspended generator).
The VM has an outer loop that pops a frame off the frame stack, and
then enters an inner loop either driving the execution of the
bytecode or the execution of a generator.
Both types of frames have several branches that can result in the
frame re-enqueuing itself, and enqueuing some other work (in the
form of a different frame) on top of itself. The VM will eventually
resume the frame when everything "above" it has been suspended.
In this way, the VM's new frame stack takes over much of the work
that was previously achieved by recursion.
2. All methods previously taking a VM have been refactored into async
functions that instead emit/receive generator messages for
communication with the VM.
Notably, this includes *all* builtins.
This has had some other effects:
- Some test have been removed or commented out, either because they
tested code that was mostly already dead (nix_eq) or because they
now require generator scaffolding which we do not have in place for
tests (yet).
- Because generator functions are technically async (though no async
IO is involved), we lose the ability to use much of the Rust
standard library e.g. in builtins. This has led to many algorithms
being unrolled into iterative versions instead of iterator
combinations, and things like sorting had to be implemented from scratch.
- Many call sites that previously saw a `Result<..., ErrorKind>`
bubble up now only see the result value, as the error handling is
encapsulated within the generator loop.
This reduces number of places inside of builtin implementations
where error context can be attached to calls that can fail.
Currently what we gain in this tradeoff is significantly more
detailed span information (which we still need to bubble up, this
commit does not change the error display).
We'll need to do some analysis later of how useful the errors turn
out to be and potentially introduce some methods for attaching
context to a generator frame again.
This change is very difficult to do in stages, as it is very much an
"all or nothing" change that affects huge parts of the codebase. I've
tried to isolate changes that can be isolated into the parent CLs of
this one, but this change is still quite difficult to wrap one's mind
and I'm available to discuss it and explain things to any reviewer.
Fixes: b/238, b/237, b/251 and potentially others.
Change-Id: I39244163ff5bbecd169fe7b274df19262b515699
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8104
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
Reviewed-by: Adam Joseph <adam@westernsemico.com>
Tested-by: BuildkiteCI
2023-02-14 15:02:39 +03:00
|
|
|
async fn builtin_derivation_strict(
|
2023-01-23 01:44:24 +03:00
|
|
|
state: Rc<RefCell<KnownPaths>>,
|
refactor(tvix/eval): flatten call stack of VM using generators
Warning: This is probably the biggest refactor in tvix-eval history,
so far.
This replaces all instances of trampolines and recursion during
evaluation of the VM loop with generators. A generator is an
asynchronous function that can be suspended to yield a message (in our
case, vm::generators::GeneratorRequest) and receive a
response (vm::generators::GeneratorResponsee).
The `genawaiter` crate provides an interpreter for generators that can
drive their execution and lets us move control flow between the VM and
suspended generators.
To do this, massive changes have occured basically everywhere in the
code. On a high-level:
1. The VM is now organised around a frame stack. A frame is either a
call frame (execution of Tvix bytecode) or a generator frame (a
running or suspended generator).
The VM has an outer loop that pops a frame off the frame stack, and
then enters an inner loop either driving the execution of the
bytecode or the execution of a generator.
Both types of frames have several branches that can result in the
frame re-enqueuing itself, and enqueuing some other work (in the
form of a different frame) on top of itself. The VM will eventually
resume the frame when everything "above" it has been suspended.
In this way, the VM's new frame stack takes over much of the work
that was previously achieved by recursion.
2. All methods previously taking a VM have been refactored into async
functions that instead emit/receive generator messages for
communication with the VM.
Notably, this includes *all* builtins.
This has had some other effects:
- Some test have been removed or commented out, either because they
tested code that was mostly already dead (nix_eq) or because they
now require generator scaffolding which we do not have in place for
tests (yet).
- Because generator functions are technically async (though no async
IO is involved), we lose the ability to use much of the Rust
standard library e.g. in builtins. This has led to many algorithms
being unrolled into iterative versions instead of iterator
combinations, and things like sorting had to be implemented from scratch.
- Many call sites that previously saw a `Result<..., ErrorKind>`
bubble up now only see the result value, as the error handling is
encapsulated within the generator loop.
This reduces number of places inside of builtin implementations
where error context can be attached to calls that can fail.
Currently what we gain in this tradeoff is significantly more
detailed span information (which we still need to bubble up, this
commit does not change the error display).
We'll need to do some analysis later of how useful the errors turn
out to be and potentially introduce some methods for attaching
context to a generator frame again.
This change is very difficult to do in stages, as it is very much an
"all or nothing" change that affects huge parts of the codebase. I've
tried to isolate changes that can be isolated into the parent CLs of
this one, but this change is still quite difficult to wrap one's mind
and I'm available to discuss it and explain things to any reviewer.
Fixes: b/238, b/237, b/251 and potentially others.
Change-Id: I39244163ff5bbecd169fe7b274df19262b515699
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8104
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
Reviewed-by: Adam Joseph <adam@westernsemico.com>
Tested-by: BuildkiteCI
2023-02-14 15:02:39 +03:00
|
|
|
co: GenCo,
|
2023-01-23 01:44:24 +03:00
|
|
|
input: Value,
|
|
|
|
) -> Result<Value, ErrorKind> {
|
2023-12-30 03:21:45 +01:00
|
|
|
if input.is_catchable() {
|
|
|
|
return Ok(input);
|
|
|
|
}
|
|
|
|
|
2023-01-23 01:44:24 +03:00
|
|
|
let input = input.to_attrs()?;
|
2023-12-30 03:21:45 +01:00
|
|
|
let name = generators::request_force(&co, input.select_required("name")?.clone()).await;
|
|
|
|
|
|
|
|
if name.is_catchable() {
|
|
|
|
return Ok(name);
|
|
|
|
}
|
|
|
|
|
|
|
|
let name = name.to_str().context("determining derivation name")?;
|
2023-01-23 01:44:24 +03:00
|
|
|
|
2023-09-23 12:38:35 +03:00
|
|
|
if name.is_empty() {
|
|
|
|
return Err(ErrorKind::Abort("derivation has empty name".to_string()));
|
|
|
|
}
|
|
|
|
|
feat(tvix/glue/derivationStrict): support __structuredAttrs
This adds support to handle the __structuredAttrs argument, which can be
passed to builtins.derivationStrict.
If __structuredAttrs is passed, and set to true, most of the arguments
passed to builtins.derivationStrict are not simply coerced to a string
and passed down to "environments", but instead kept in a more structured
fashion.
Inside ATerm, which is what's relevant as far as path calculation is
concerned, a virtual `__json` environment variable is present,
containing these structured values.
Inside Builds, these structured values are not made available as an
environment variable, but a JSON file (and source-able bash script).
This will need to be respected once we start emitting BuildRequests,
and for that we can probably just parse the `__json` key in
Derivation.environment again - or keep this additionally in
non-serialized form around during Evaluation.
No matter what, this is left for a followup CL.
The existing handle_derivation_parameters and populate_outputs helper
function were removed, as __structuredAttrs causes quite a change
in behaviour, and so handling both in the same place makes it more
readable.
There's some open questions w.r.t. string contexts for structured attrs
itself. A TODO is left for this, but at least path calculation for
individual structured attrs derivations are correct now.
Part of b/366.
Change-Id: Ic293822266ced6f8c4826d8ef0d2e098a4adccaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10604
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2024-01-11 15:44:31 +02:00
|
|
|
let mut drv = Derivation::default();
|
|
|
|
drv.outputs.insert("out".to_string(), Default::default());
|
|
|
|
let mut input_context = NixContext::new();
|
|
|
|
|
|
|
|
#[inline]
|
|
|
|
async fn strong_importing_coerce_to_string(
|
|
|
|
co: &GenCo,
|
|
|
|
val: Value,
|
|
|
|
) -> Result<NixString, CatchableErrorKind> {
|
|
|
|
let val = generators::request_force(co, val).await;
|
|
|
|
match generators::request_string_coerce(
|
|
|
|
co,
|
|
|
|
val,
|
|
|
|
CoercionKind {
|
|
|
|
strong: true,
|
|
|
|
import_paths: true,
|
|
|
|
},
|
|
|
|
)
|
|
|
|
.await
|
|
|
|
{
|
|
|
|
Err(cek) => Err(cek),
|
|
|
|
Ok(val_str) => Ok(val_str),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Inserts a key and value into the drv.environment BTreeMap, and fails if the
|
|
|
|
/// key did already exist before.
|
|
|
|
fn insert_env(drv: &mut Derivation, k: &str, v: BString) -> Result<(), DerivationError> {
|
|
|
|
if drv.environment.insert(k.into(), v).is_some() {
|
|
|
|
return Err(DerivationError::DuplicateEnvVar(k.into()));
|
2023-01-23 01:44:24 +03:00
|
|
|
}
|
feat(tvix/glue/derivationStrict): support __structuredAttrs
This adds support to handle the __structuredAttrs argument, which can be
passed to builtins.derivationStrict.
If __structuredAttrs is passed, and set to true, most of the arguments
passed to builtins.derivationStrict are not simply coerced to a string
and passed down to "environments", but instead kept in a more structured
fashion.
Inside ATerm, which is what's relevant as far as path calculation is
concerned, a virtual `__json` environment variable is present,
containing these structured values.
Inside Builds, these structured values are not made available as an
environment variable, but a JSON file (and source-able bash script).
This will need to be respected once we start emitting BuildRequests,
and for that we can probably just parse the `__json` key in
Derivation.environment again - or keep this additionally in
non-serialized form around during Evaluation.
No matter what, this is left for a followup CL.
The existing handle_derivation_parameters and populate_outputs helper
function were removed, as __structuredAttrs causes quite a change
in behaviour, and so handling both in the same place makes it more
readable.
There's some open questions w.r.t. string contexts for structured attrs
itself. A TODO is left for this, but at least path calculation for
individual structured attrs derivations are correct now.
Part of b/366.
Change-Id: Ic293822266ced6f8c4826d8ef0d2e098a4adccaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10604
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2024-01-11 15:44:31 +02:00
|
|
|
Ok(())
|
2023-01-23 01:44:24 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// Check whether null attributes should be ignored or passed through.
|
|
|
|
let ignore_nulls = match input.select(IGNORE_NULLS) {
|
refactor(tvix/eval): flatten call stack of VM using generators
Warning: This is probably the biggest refactor in tvix-eval history,
so far.
This replaces all instances of trampolines and recursion during
evaluation of the VM loop with generators. A generator is an
asynchronous function that can be suspended to yield a message (in our
case, vm::generators::GeneratorRequest) and receive a
response (vm::generators::GeneratorResponsee).
The `genawaiter` crate provides an interpreter for generators that can
drive their execution and lets us move control flow between the VM and
suspended generators.
To do this, massive changes have occured basically everywhere in the
code. On a high-level:
1. The VM is now organised around a frame stack. A frame is either a
call frame (execution of Tvix bytecode) or a generator frame (a
running or suspended generator).
The VM has an outer loop that pops a frame off the frame stack, and
then enters an inner loop either driving the execution of the
bytecode or the execution of a generator.
Both types of frames have several branches that can result in the
frame re-enqueuing itself, and enqueuing some other work (in the
form of a different frame) on top of itself. The VM will eventually
resume the frame when everything "above" it has been suspended.
In this way, the VM's new frame stack takes over much of the work
that was previously achieved by recursion.
2. All methods previously taking a VM have been refactored into async
functions that instead emit/receive generator messages for
communication with the VM.
Notably, this includes *all* builtins.
This has had some other effects:
- Some test have been removed or commented out, either because they
tested code that was mostly already dead (nix_eq) or because they
now require generator scaffolding which we do not have in place for
tests (yet).
- Because generator functions are technically async (though no async
IO is involved), we lose the ability to use much of the Rust
standard library e.g. in builtins. This has led to many algorithms
being unrolled into iterative versions instead of iterator
combinations, and things like sorting had to be implemented from scratch.
- Many call sites that previously saw a `Result<..., ErrorKind>`
bubble up now only see the result value, as the error handling is
encapsulated within the generator loop.
This reduces number of places inside of builtin implementations
where error context can be attached to calls that can fail.
Currently what we gain in this tradeoff is significantly more
detailed span information (which we still need to bubble up, this
commit does not change the error display).
We'll need to do some analysis later of how useful the errors turn
out to be and potentially introduce some methods for attaching
context to a generator frame again.
This change is very difficult to do in stages, as it is very much an
"all or nothing" change that affects huge parts of the codebase. I've
tried to isolate changes that can be isolated into the parent CLs of
this one, but this change is still quite difficult to wrap one's mind
and I'm available to discuss it and explain things to any reviewer.
Fixes: b/238, b/237, b/251 and potentially others.
Change-Id: I39244163ff5bbecd169fe7b274df19262b515699
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8104
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
Reviewed-by: Adam Joseph <adam@westernsemico.com>
Tested-by: BuildkiteCI
2023-02-14 15:02:39 +03:00
|
|
|
Some(b) => generators::request_force(&co, b.clone()).await.as_bool()?,
|
2023-01-23 01:44:24 +03:00
|
|
|
None => false,
|
|
|
|
};
|
|
|
|
|
feat(tvix/glue/derivationStrict): support __structuredAttrs
This adds support to handle the __structuredAttrs argument, which can be
passed to builtins.derivationStrict.
If __structuredAttrs is passed, and set to true, most of the arguments
passed to builtins.derivationStrict are not simply coerced to a string
and passed down to "environments", but instead kept in a more structured
fashion.
Inside ATerm, which is what's relevant as far as path calculation is
concerned, a virtual `__json` environment variable is present,
containing these structured values.
Inside Builds, these structured values are not made available as an
environment variable, but a JSON file (and source-able bash script).
This will need to be respected once we start emitting BuildRequests,
and for that we can probably just parse the `__json` key in
Derivation.environment again - or keep this additionally in
non-serialized form around during Evaluation.
No matter what, this is left for a followup CL.
The existing handle_derivation_parameters and populate_outputs helper
function were removed, as __structuredAttrs causes quite a change
in behaviour, and so handling both in the same place makes it more
readable.
There's some open questions w.r.t. string contexts for structured attrs
itself. A TODO is left for this, but at least path calculation for
individual structured attrs derivations are correct now.
Part of b/366.
Change-Id: Ic293822266ced6f8c4826d8ef0d2e098a4adccaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10604
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2024-01-11 15:44:31 +02:00
|
|
|
// peek at the STRUCTURED_ATTRS argument.
|
|
|
|
// If it's set and true, provide a BTreeMap that gets populated while looking at the arguments.
|
|
|
|
// We need it to be a BTreeMap, so iteration order of keys is reproducible.
|
|
|
|
let mut structured_attrs: Option<BTreeMap<String, serde_json::Value>> =
|
|
|
|
match input.select(STRUCTURED_ATTRS) {
|
|
|
|
Some(b) => generators::request_force(&co, b.clone())
|
|
|
|
.await
|
|
|
|
.as_bool()?
|
|
|
|
.then_some(Default::default()),
|
|
|
|
None => None,
|
|
|
|
};
|
refactor(tvix/eval): flatten call stack of VM using generators
Warning: This is probably the biggest refactor in tvix-eval history,
so far.
This replaces all instances of trampolines and recursion during
evaluation of the VM loop with generators. A generator is an
asynchronous function that can be suspended to yield a message (in our
case, vm::generators::GeneratorRequest) and receive a
response (vm::generators::GeneratorResponsee).
The `genawaiter` crate provides an interpreter for generators that can
drive their execution and lets us move control flow between the VM and
suspended generators.
To do this, massive changes have occured basically everywhere in the
code. On a high-level:
1. The VM is now organised around a frame stack. A frame is either a
call frame (execution of Tvix bytecode) or a generator frame (a
running or suspended generator).
The VM has an outer loop that pops a frame off the frame stack, and
then enters an inner loop either driving the execution of the
bytecode or the execution of a generator.
Both types of frames have several branches that can result in the
frame re-enqueuing itself, and enqueuing some other work (in the
form of a different frame) on top of itself. The VM will eventually
resume the frame when everything "above" it has been suspended.
In this way, the VM's new frame stack takes over much of the work
that was previously achieved by recursion.
2. All methods previously taking a VM have been refactored into async
functions that instead emit/receive generator messages for
communication with the VM.
Notably, this includes *all* builtins.
This has had some other effects:
- Some test have been removed or commented out, either because they
tested code that was mostly already dead (nix_eq) or because they
now require generator scaffolding which we do not have in place for
tests (yet).
- Because generator functions are technically async (though no async
IO is involved), we lose the ability to use much of the Rust
standard library e.g. in builtins. This has led to many algorithms
being unrolled into iterative versions instead of iterator
combinations, and things like sorting had to be implemented from scratch.
- Many call sites that previously saw a `Result<..., ErrorKind>`
bubble up now only see the result value, as the error handling is
encapsulated within the generator loop.
This reduces number of places inside of builtin implementations
where error context can be attached to calls that can fail.
Currently what we gain in this tradeoff is significantly more
detailed span information (which we still need to bubble up, this
commit does not change the error display).
We'll need to do some analysis later of how useful the errors turn
out to be and potentially introduce some methods for attaching
context to a generator frame again.
This change is very difficult to do in stages, as it is very much an
"all or nothing" change that affects huge parts of the codebase. I've
tried to isolate changes that can be isolated into the parent CLs of
this one, but this change is still quite difficult to wrap one's mind
and I'm available to discuss it and explain things to any reviewer.
Fixes: b/238, b/237, b/251 and potentially others.
Change-Id: I39244163ff5bbecd169fe7b274df19262b515699
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8104
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
Reviewed-by: Adam Joseph <adam@westernsemico.com>
Tested-by: BuildkiteCI
2023-02-14 15:02:39 +03:00
|
|
|
|
feat(tvix/glue/derivationStrict): support __structuredAttrs
This adds support to handle the __structuredAttrs argument, which can be
passed to builtins.derivationStrict.
If __structuredAttrs is passed, and set to true, most of the arguments
passed to builtins.derivationStrict are not simply coerced to a string
and passed down to "environments", but instead kept in a more structured
fashion.
Inside ATerm, which is what's relevant as far as path calculation is
concerned, a virtual `__json` environment variable is present,
containing these structured values.
Inside Builds, these structured values are not made available as an
environment variable, but a JSON file (and source-able bash script).
This will need to be respected once we start emitting BuildRequests,
and for that we can probably just parse the `__json` key in
Derivation.environment again - or keep this additionally in
non-serialized form around during Evaluation.
No matter what, this is left for a followup CL.
The existing handle_derivation_parameters and populate_outputs helper
function were removed, as __structuredAttrs causes quite a change
in behaviour, and so handling both in the same place makes it more
readable.
There's some open questions w.r.t. string contexts for structured attrs
itself. A TODO is left for this, but at least path calculation for
individual structured attrs derivations are correct now.
Part of b/366.
Change-Id: Ic293822266ced6f8c4826d8ef0d2e098a4adccaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10604
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2024-01-11 15:44:31 +02:00
|
|
|
// Look at the arguments passed to builtins.derivationStrict.
|
|
|
|
// Some set special fields in the Derivation struct, some change
|
|
|
|
// behaviour of other functionality.
|
|
|
|
for (arg_name, arg_value) in input.clone().into_iter_sorted() {
|
|
|
|
// force the current value.
|
|
|
|
let value = generators::request_force(&co, arg_value).await;
|
2023-12-26 02:03:05 +01:00
|
|
|
|
feat(tvix/glue/derivationStrict): support __structuredAttrs
This adds support to handle the __structuredAttrs argument, which can be
passed to builtins.derivationStrict.
If __structuredAttrs is passed, and set to true, most of the arguments
passed to builtins.derivationStrict are not simply coerced to a string
and passed down to "environments", but instead kept in a more structured
fashion.
Inside ATerm, which is what's relevant as far as path calculation is
concerned, a virtual `__json` environment variable is present,
containing these structured values.
Inside Builds, these structured values are not made available as an
environment variable, but a JSON file (and source-able bash script).
This will need to be respected once we start emitting BuildRequests,
and for that we can probably just parse the `__json` key in
Derivation.environment again - or keep this additionally in
non-serialized form around during Evaluation.
No matter what, this is left for a followup CL.
The existing handle_derivation_parameters and populate_outputs helper
function were removed, as __structuredAttrs causes quite a change
in behaviour, and so handling both in the same place makes it more
readable.
There's some open questions w.r.t. string contexts for structured attrs
itself. A TODO is left for this, but at least path calculation for
individual structured attrs derivations are correct now.
Part of b/366.
Change-Id: Ic293822266ced6f8c4826d8ef0d2e098a4adccaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10604
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2024-01-11 15:44:31 +02:00
|
|
|
// filter out nulls if ignore_nulls is set.
|
refactor(tvix/eval): flatten call stack of VM using generators
Warning: This is probably the biggest refactor in tvix-eval history,
so far.
This replaces all instances of trampolines and recursion during
evaluation of the VM loop with generators. A generator is an
asynchronous function that can be suspended to yield a message (in our
case, vm::generators::GeneratorRequest) and receive a
response (vm::generators::GeneratorResponsee).
The `genawaiter` crate provides an interpreter for generators that can
drive their execution and lets us move control flow between the VM and
suspended generators.
To do this, massive changes have occured basically everywhere in the
code. On a high-level:
1. The VM is now organised around a frame stack. A frame is either a
call frame (execution of Tvix bytecode) or a generator frame (a
running or suspended generator).
The VM has an outer loop that pops a frame off the frame stack, and
then enters an inner loop either driving the execution of the
bytecode or the execution of a generator.
Both types of frames have several branches that can result in the
frame re-enqueuing itself, and enqueuing some other work (in the
form of a different frame) on top of itself. The VM will eventually
resume the frame when everything "above" it has been suspended.
In this way, the VM's new frame stack takes over much of the work
that was previously achieved by recursion.
2. All methods previously taking a VM have been refactored into async
functions that instead emit/receive generator messages for
communication with the VM.
Notably, this includes *all* builtins.
This has had some other effects:
- Some test have been removed or commented out, either because they
tested code that was mostly already dead (nix_eq) or because they
now require generator scaffolding which we do not have in place for
tests (yet).
- Because generator functions are technically async (though no async
IO is involved), we lose the ability to use much of the Rust
standard library e.g. in builtins. This has led to many algorithms
being unrolled into iterative versions instead of iterator
combinations, and things like sorting had to be implemented from scratch.
- Many call sites that previously saw a `Result<..., ErrorKind>`
bubble up now only see the result value, as the error handling is
encapsulated within the generator loop.
This reduces number of places inside of builtin implementations
where error context can be attached to calls that can fail.
Currently what we gain in this tradeoff is significantly more
detailed span information (which we still need to bubble up, this
commit does not change the error display).
We'll need to do some analysis later of how useful the errors turn
out to be and potentially introduce some methods for attaching
context to a generator frame again.
This change is very difficult to do in stages, as it is very much an
"all or nothing" change that affects huge parts of the codebase. I've
tried to isolate changes that can be isolated into the parent CLs of
this one, but this change is still quite difficult to wrap one's mind
and I'm available to discuss it and explain things to any reviewer.
Fixes: b/238, b/237, b/251 and potentially others.
Change-Id: I39244163ff5bbecd169fe7b274df19262b515699
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8104
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
Reviewed-by: Adam Joseph <adam@westernsemico.com>
Tested-by: BuildkiteCI
2023-02-14 15:02:39 +03:00
|
|
|
if ignore_nulls && matches!(value, Value::Null) {
|
2023-01-23 01:44:24 +03:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
feat(tvix/glue/derivationStrict): support __structuredAttrs
This adds support to handle the __structuredAttrs argument, which can be
passed to builtins.derivationStrict.
If __structuredAttrs is passed, and set to true, most of the arguments
passed to builtins.derivationStrict are not simply coerced to a string
and passed down to "environments", but instead kept in a more structured
fashion.
Inside ATerm, which is what's relevant as far as path calculation is
concerned, a virtual `__json` environment variable is present,
containing these structured values.
Inside Builds, these structured values are not made available as an
environment variable, but a JSON file (and source-able bash script).
This will need to be respected once we start emitting BuildRequests,
and for that we can probably just parse the `__json` key in
Derivation.environment again - or keep this additionally in
non-serialized form around during Evaluation.
No matter what, this is left for a followup CL.
The existing handle_derivation_parameters and populate_outputs helper
function were removed, as __structuredAttrs causes quite a change
in behaviour, and so handling both in the same place makes it more
readable.
There's some open questions w.r.t. string contexts for structured attrs
itself. A TODO is left for this, but at least path calculation for
individual structured attrs derivations are correct now.
Part of b/366.
Change-Id: Ic293822266ced6f8c4826d8ef0d2e098a4adccaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10604
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2024-01-11 15:44:31 +02:00
|
|
|
match arg_name.as_str() {
|
|
|
|
// Command line arguments to the builder.
|
|
|
|
// These are only set in drv.arguments.
|
|
|
|
"args" => {
|
|
|
|
for arg in value.to_list()? {
|
|
|
|
match strong_importing_coerce_to_string(&co, arg).await {
|
|
|
|
Err(cek) => return Ok(Value::Catchable(cek)),
|
|
|
|
Ok(s) => {
|
|
|
|
input_context.mimic(&s);
|
|
|
|
drv.arguments.push(s.as_str().to_string())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// If outputs is set, remove the original default `out` output,
|
|
|
|
// and replace it with the list of outputs.
|
|
|
|
"outputs" => {
|
|
|
|
let outputs = value
|
|
|
|
.to_list()
|
|
|
|
.context("looking at the `outputs` parameter of the derivation")?;
|
|
|
|
|
|
|
|
// Remove the original default `out` output.
|
|
|
|
drv.outputs.clear();
|
|
|
|
|
|
|
|
let mut output_names = vec![];
|
|
|
|
|
|
|
|
for output in outputs {
|
|
|
|
let output_name = generators::request_force(&co, output)
|
|
|
|
.await
|
|
|
|
.to_str()
|
|
|
|
.context("determining output name")?;
|
|
|
|
|
|
|
|
input_context.mimic(&output_name);
|
|
|
|
|
|
|
|
// Populate drv.outputs
|
|
|
|
if drv
|
|
|
|
.outputs
|
|
|
|
.insert(output_name.as_str().to_string(), Default::default())
|
|
|
|
.is_some()
|
|
|
|
{
|
|
|
|
Err(DerivationError::DuplicateOutput(
|
|
|
|
output_name.as_str().into(),
|
|
|
|
))?
|
|
|
|
}
|
|
|
|
output_names.push(output_name.as_str().to_string());
|
|
|
|
}
|
|
|
|
|
|
|
|
// Add drv.environment[outputs] unconditionally.
|
|
|
|
insert_env(&mut drv, arg_name.as_str(), output_names.join(" ").into())?;
|
|
|
|
// drv.environment[$output_name] is added after the loop,
|
|
|
|
// with whatever is in drv.outputs[$output_name].
|
|
|
|
}
|
|
|
|
|
|
|
|
// handle builder and system.
|
|
|
|
"builder" | "system" => {
|
|
|
|
match strong_importing_coerce_to_string(&co, value).await {
|
2023-09-09 22:02:56 -07:00
|
|
|
Err(cek) => return Ok(Value::Catchable(cek)),
|
feat(tvix/glue/derivationStrict): support __structuredAttrs
This adds support to handle the __structuredAttrs argument, which can be
passed to builtins.derivationStrict.
If __structuredAttrs is passed, and set to true, most of the arguments
passed to builtins.derivationStrict are not simply coerced to a string
and passed down to "environments", but instead kept in a more structured
fashion.
Inside ATerm, which is what's relevant as far as path calculation is
concerned, a virtual `__json` environment variable is present,
containing these structured values.
Inside Builds, these structured values are not made available as an
environment variable, but a JSON file (and source-able bash script).
This will need to be respected once we start emitting BuildRequests,
and for that we can probably just parse the `__json` key in
Derivation.environment again - or keep this additionally in
non-serialized form around during Evaluation.
No matter what, this is left for a followup CL.
The existing handle_derivation_parameters and populate_outputs helper
function were removed, as __structuredAttrs causes quite a change
in behaviour, and so handling both in the same place makes it more
readable.
There's some open questions w.r.t. string contexts for structured attrs
itself. A TODO is left for this, but at least path calculation for
individual structured attrs derivations are correct now.
Part of b/366.
Change-Id: Ic293822266ced6f8c4826d8ef0d2e098a4adccaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10604
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2024-01-11 15:44:31 +02:00
|
|
|
Ok(val_str) => {
|
|
|
|
input_context.mimic(&val_str);
|
|
|
|
|
|
|
|
if arg_name.as_str() == "builder" {
|
|
|
|
drv.builder = val_str.as_str().to_owned();
|
|
|
|
} else {
|
|
|
|
drv.system = val_str.as_str().to_owned();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Either populate drv.environment or structured_attrs.
|
|
|
|
if let Some(ref mut structured_attrs) = structured_attrs {
|
|
|
|
// No need to check for dups, we only iterate over every attribute name once
|
|
|
|
structured_attrs
|
|
|
|
.insert(arg_name.as_str().into(), val_str.as_str().into());
|
|
|
|
} else {
|
|
|
|
insert_env(&mut drv, arg_name.as_str(), val_str.as_bytes().into())?;
|
|
|
|
}
|
|
|
|
}
|
2023-09-09 22:02:56 -07:00
|
|
|
}
|
feat(tvix/glue/derivationStrict): support __structuredAttrs
This adds support to handle the __structuredAttrs argument, which can be
passed to builtins.derivationStrict.
If __structuredAttrs is passed, and set to true, most of the arguments
passed to builtins.derivationStrict are not simply coerced to a string
and passed down to "environments", but instead kept in a more structured
fashion.
Inside ATerm, which is what's relevant as far as path calculation is
concerned, a virtual `__json` environment variable is present,
containing these structured values.
Inside Builds, these structured values are not made available as an
environment variable, but a JSON file (and source-able bash script).
This will need to be respected once we start emitting BuildRequests,
and for that we can probably just parse the `__json` key in
Derivation.environment again - or keep this additionally in
non-serialized form around during Evaluation.
No matter what, this is left for a followup CL.
The existing handle_derivation_parameters and populate_outputs helper
function were removed, as __structuredAttrs causes quite a change
in behaviour, and so handling both in the same place makes it more
readable.
There's some open questions w.r.t. string contexts for structured attrs
itself. A TODO is left for this, but at least path calculation for
individual structured attrs derivations are correct now.
Part of b/366.
Change-Id: Ic293822266ced6f8c4826d8ef0d2e098a4adccaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10604
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2024-01-11 15:44:31 +02:00
|
|
|
}
|
2023-01-23 01:44:24 +03:00
|
|
|
|
feat(tvix/glue/derivationStrict): support __structuredAttrs
This adds support to handle the __structuredAttrs argument, which can be
passed to builtins.derivationStrict.
If __structuredAttrs is passed, and set to true, most of the arguments
passed to builtins.derivationStrict are not simply coerced to a string
and passed down to "environments", but instead kept in a more structured
fashion.
Inside ATerm, which is what's relevant as far as path calculation is
concerned, a virtual `__json` environment variable is present,
containing these structured values.
Inside Builds, these structured values are not made available as an
environment variable, but a JSON file (and source-able bash script).
This will need to be respected once we start emitting BuildRequests,
and for that we can probably just parse the `__json` key in
Derivation.environment again - or keep this additionally in
non-serialized form around during Evaluation.
No matter what, this is left for a followup CL.
The existing handle_derivation_parameters and populate_outputs helper
function were removed, as __structuredAttrs causes quite a change
in behaviour, and so handling both in the same place makes it more
readable.
There's some open questions w.r.t. string contexts for structured attrs
itself. A TODO is left for this, but at least path calculation for
individual structured attrs derivations are correct now.
Part of b/366.
Change-Id: Ic293822266ced6f8c4826d8ef0d2e098a4adccaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10604
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2024-01-11 15:44:31 +02:00
|
|
|
// Don't add STRUCTURED_ATTRS if enabled.
|
|
|
|
STRUCTURED_ATTRS if structured_attrs.is_some() => continue,
|
|
|
|
// IGNORE_NULLS is always skipped, even if it's not set to true.
|
|
|
|
IGNORE_NULLS => continue,
|
|
|
|
|
|
|
|
// all other args.
|
|
|
|
_ => {
|
|
|
|
// In SA case, force and add to structured attrs.
|
|
|
|
// In non-SA case, coerce to string and add to env.
|
|
|
|
if let Some(ref mut structured_attrs) = structured_attrs {
|
|
|
|
let val = generators::request_force(&co, value).await;
|
|
|
|
if matches!(val, Value::Catchable(_)) {
|
|
|
|
return Ok(val);
|
|
|
|
}
|
|
|
|
|
|
|
|
// TODO(raitobezarius): context for json values?
|
|
|
|
// input_context.mimic(&val);
|
|
|
|
|
|
|
|
let val_json = match val.into_json(&co).await? {
|
|
|
|
Ok(v) => v,
|
|
|
|
Err(cek) => return Ok(Value::Catchable(cek)),
|
|
|
|
};
|
|
|
|
|
|
|
|
// No need to check for dups, we only iterate over every attribute name once
|
|
|
|
structured_attrs.insert(arg_name.as_str().to_string(), val_json);
|
|
|
|
} else {
|
|
|
|
match strong_importing_coerce_to_string(&co, value).await {
|
|
|
|
Err(cek) => return Ok(Value::Catchable(cek)),
|
|
|
|
Ok(val_str) => {
|
|
|
|
input_context.mimic(&val_str);
|
|
|
|
|
|
|
|
insert_env(&mut drv, arg_name.as_str(), val_str.as_bytes().into())?;
|
|
|
|
}
|
|
|
|
}
|
2023-09-09 22:02:56 -07:00
|
|
|
}
|
|
|
|
}
|
2023-01-23 01:44:24 +03:00
|
|
|
}
|
|
|
|
}
|
feat(tvix/glue/derivationStrict): support __structuredAttrs
This adds support to handle the __structuredAttrs argument, which can be
passed to builtins.derivationStrict.
If __structuredAttrs is passed, and set to true, most of the arguments
passed to builtins.derivationStrict are not simply coerced to a string
and passed down to "environments", but instead kept in a more structured
fashion.
Inside ATerm, which is what's relevant as far as path calculation is
concerned, a virtual `__json` environment variable is present,
containing these structured values.
Inside Builds, these structured values are not made available as an
environment variable, but a JSON file (and source-able bash script).
This will need to be respected once we start emitting BuildRequests,
and for that we can probably just parse the `__json` key in
Derivation.environment again - or keep this additionally in
non-serialized form around during Evaluation.
No matter what, this is left for a followup CL.
The existing handle_derivation_parameters and populate_outputs helper
function were removed, as __structuredAttrs causes quite a change
in behaviour, and so handling both in the same place makes it more
readable.
There's some open questions w.r.t. string contexts for structured attrs
itself. A TODO is left for this, but at least path calculation for
individual structured attrs derivations are correct now.
Part of b/366.
Change-Id: Ic293822266ced6f8c4826d8ef0d2e098a4adccaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10604
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2024-01-11 15:44:31 +02:00
|
|
|
// end of per-argument loop
|
2023-01-23 01:44:24 +03:00
|
|
|
|
2023-10-22 22:24:33 +01:00
|
|
|
// Configure fixed-output derivations if required.
|
2023-09-09 22:02:56 -07:00
|
|
|
{
|
feat(tvix/glue/derivationStrict): support __structuredAttrs
This adds support to handle the __structuredAttrs argument, which can be
passed to builtins.derivationStrict.
If __structuredAttrs is passed, and set to true, most of the arguments
passed to builtins.derivationStrict are not simply coerced to a string
and passed down to "environments", but instead kept in a more structured
fashion.
Inside ATerm, which is what's relevant as far as path calculation is
concerned, a virtual `__json` environment variable is present,
containing these structured values.
Inside Builds, these structured values are not made available as an
environment variable, but a JSON file (and source-able bash script).
This will need to be respected once we start emitting BuildRequests,
and for that we can probably just parse the `__json` key in
Derivation.environment again - or keep this additionally in
non-serialized form around during Evaluation.
No matter what, this is left for a followup CL.
The existing handle_derivation_parameters and populate_outputs helper
function were removed, as __structuredAttrs causes quite a change
in behaviour, and so handling both in the same place makes it more
readable.
There's some open questions w.r.t. string contexts for structured attrs
itself. A TODO is left for this, but at least path calculation for
individual structured attrs derivations are correct now.
Part of b/366.
Change-Id: Ic293822266ced6f8c4826d8ef0d2e098a4adccaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10604
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2024-01-11 15:44:31 +02:00
|
|
|
async fn select_string(
|
|
|
|
co: &GenCo,
|
|
|
|
attrs: &NixAttrs,
|
|
|
|
key: &str,
|
|
|
|
) -> Result<Result<Option<String>, CatchableErrorKind>, ErrorKind> {
|
|
|
|
if let Some(attr) = attrs.select(key) {
|
|
|
|
match strong_importing_coerce_to_string(co, attr.clone()).await {
|
|
|
|
Err(cek) => return Ok(Err(cek)),
|
|
|
|
Ok(str) => return Ok(Ok(Some(str.as_str().to_string()))),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Ok(Ok(None))
|
|
|
|
}
|
|
|
|
|
2023-10-22 22:24:33 +01:00
|
|
|
let output_hash = match select_string(&co, &input, "outputHash")
|
|
|
|
.await
|
|
|
|
.context("evaluating the `outputHash` parameter")?
|
|
|
|
{
|
|
|
|
Err(cek) => return Ok(Value::Catchable(cek)),
|
|
|
|
Ok(s) => s,
|
|
|
|
};
|
|
|
|
let output_hash_algo = match select_string(&co, &input, "outputHashAlgo")
|
|
|
|
.await
|
|
|
|
.context("evaluating the `outputHashAlgo` parameter")?
|
|
|
|
{
|
|
|
|
Err(cek) => return Ok(Value::Catchable(cek)),
|
|
|
|
Ok(s) => s,
|
|
|
|
};
|
|
|
|
let output_hash_mode = match select_string(&co, &input, "outputHashMode")
|
|
|
|
.await
|
|
|
|
.context("evaluating the `outputHashMode` parameter")?
|
|
|
|
{
|
|
|
|
Err(cek) => return Ok(Value::Catchable(cek)),
|
|
|
|
Ok(s) => s,
|
|
|
|
};
|
2023-12-30 03:01:59 +01:00
|
|
|
|
|
|
|
if let Some(warning) =
|
|
|
|
handle_fixed_output(&mut drv, output_hash, output_hash_algo, output_hash_mode)?
|
|
|
|
{
|
|
|
|
emit_warning_kind(&co, warning).await;
|
|
|
|
}
|
2023-10-22 22:24:33 +01:00
|
|
|
}
|
2023-03-15 15:24:14 +03:00
|
|
|
|
2023-01-23 01:44:24 +03:00
|
|
|
// Each output name needs to exist in the environment, at this
|
feat(tvix/glue/derivationStrict): support __structuredAttrs
This adds support to handle the __structuredAttrs argument, which can be
passed to builtins.derivationStrict.
If __structuredAttrs is passed, and set to true, most of the arguments
passed to builtins.derivationStrict are not simply coerced to a string
and passed down to "environments", but instead kept in a more structured
fashion.
Inside ATerm, which is what's relevant as far as path calculation is
concerned, a virtual `__json` environment variable is present,
containing these structured values.
Inside Builds, these structured values are not made available as an
environment variable, but a JSON file (and source-able bash script).
This will need to be respected once we start emitting BuildRequests,
and for that we can probably just parse the `__json` key in
Derivation.environment again - or keep this additionally in
non-serialized form around during Evaluation.
No matter what, this is left for a followup CL.
The existing handle_derivation_parameters and populate_outputs helper
function were removed, as __structuredAttrs causes quite a change
in behaviour, and so handling both in the same place makes it more
readable.
There's some open questions w.r.t. string contexts for structured attrs
itself. A TODO is left for this, but at least path calculation for
individual structured attrs derivations are correct now.
Part of b/366.
Change-Id: Ic293822266ced6f8c4826d8ef0d2e098a4adccaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10604
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2024-01-11 15:44:31 +02:00
|
|
|
// point initialised as an empty string, as the ATerm serialization of that is later
|
|
|
|
// used for the output path calculation (which will also update output
|
|
|
|
// paths post-calculation, both in drv.environment and drv.outputs)
|
2023-01-23 01:44:24 +03:00
|
|
|
for output in drv.outputs.keys() {
|
|
|
|
if drv
|
|
|
|
.environment
|
2023-07-29 21:14:44 +02:00
|
|
|
.insert(output.to_string(), String::new().into())
|
2023-01-23 01:44:24 +03:00
|
|
|
.is_some()
|
|
|
|
{
|
2023-06-01 21:21:23 +02:00
|
|
|
emit_warning_kind(&co, WarningKind::ShadowedOutput(output.to_string())).await;
|
2023-01-23 01:44:24 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
feat(tvix/glue/derivationStrict): support __structuredAttrs
This adds support to handle the __structuredAttrs argument, which can be
passed to builtins.derivationStrict.
If __structuredAttrs is passed, and set to true, most of the arguments
passed to builtins.derivationStrict are not simply coerced to a string
and passed down to "environments", but instead kept in a more structured
fashion.
Inside ATerm, which is what's relevant as far as path calculation is
concerned, a virtual `__json` environment variable is present,
containing these structured values.
Inside Builds, these structured values are not made available as an
environment variable, but a JSON file (and source-able bash script).
This will need to be respected once we start emitting BuildRequests,
and for that we can probably just parse the `__json` key in
Derivation.environment again - or keep this additionally in
non-serialized form around during Evaluation.
No matter what, this is left for a followup CL.
The existing handle_derivation_parameters and populate_outputs helper
function were removed, as __structuredAttrs causes quite a change
in behaviour, and so handling both in the same place makes it more
readable.
There's some open questions w.r.t. string contexts for structured attrs
itself. A TODO is left for this, but at least path calculation for
individual structured attrs derivations are correct now.
Part of b/366.
Change-Id: Ic293822266ced6f8c4826d8ef0d2e098a4adccaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10604
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2024-01-11 15:44:31 +02:00
|
|
|
if let Some(structured_attrs) = structured_attrs {
|
|
|
|
// configure __json
|
|
|
|
drv.environment.insert(
|
|
|
|
"__json".to_string(),
|
|
|
|
BString::from(serde_json::to_string(&structured_attrs)?),
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2023-12-26 02:03:05 +01:00
|
|
|
populate_inputs(&mut drv, input_context);
|
2023-01-23 01:44:24 +03:00
|
|
|
let mut known_paths = state.borrow_mut();
|
|
|
|
|
|
|
|
// At this point, derivation fields are fully populated from
|
|
|
|
// eval data structures.
|
2023-11-03 16:40:32 +02:00
|
|
|
drv.validate(false)
|
|
|
|
.map_err(DerivationError::InvalidDerivation)?;
|
2023-01-23 01:44:24 +03:00
|
|
|
|
2023-03-13 23:52:23 +01:00
|
|
|
// Calculate the derivation_or_fod_hash for the current derivation.
|
|
|
|
// This one is still intermediate (so not added to known_paths)
|
2024-01-15 20:32:55 +02:00
|
|
|
let derivation_or_fod_hash_tmp = drv.derivation_or_fod_hash(|drv_path| {
|
|
|
|
known_paths.get_hash_derivation_modulo(&drv_path.to_owned())
|
|
|
|
});
|
2023-01-23 01:44:24 +03:00
|
|
|
|
2023-03-13 23:52:23 +01:00
|
|
|
// Mutate the Derivation struct and set output paths
|
|
|
|
drv.calculate_output_paths(&name, &derivation_or_fod_hash_tmp)
|
2023-11-03 16:40:32 +02:00
|
|
|
.map_err(DerivationError::InvalidDerivation)?;
|
2023-01-23 01:44:24 +03:00
|
|
|
|
2024-01-15 20:32:55 +02:00
|
|
|
let drv_path = drv
|
2023-01-23 01:44:24 +03:00
|
|
|
.calculate_derivation_path(&name)
|
2023-11-03 16:40:32 +02:00
|
|
|
.map_err(DerivationError::InvalidDerivation)?;
|
2023-01-23 01:44:24 +03:00
|
|
|
|
2023-03-13 23:52:23 +01:00
|
|
|
// recompute the hash derivation modulo and add to known_paths
|
2024-01-15 20:32:55 +02:00
|
|
|
let derivation_or_fod_hash_final = drv.derivation_or_fod_hash(|drv_path| {
|
|
|
|
known_paths.get_hash_derivation_modulo(&drv_path.to_owned())
|
|
|
|
});
|
2023-03-13 23:52:23 +01:00
|
|
|
|
2024-01-15 20:32:55 +02:00
|
|
|
known_paths.add_hash_derivation_modulo(drv_path.clone(), &derivation_or_fod_hash_final);
|
2023-01-23 01:44:24 +03:00
|
|
|
|
2023-12-26 02:03:05 +01:00
|
|
|
let mut new_attrs: Vec<(String, NixString)> = drv
|
2023-01-23 01:44:24 +03:00
|
|
|
.outputs
|
|
|
|
.into_iter()
|
2023-12-26 02:03:05 +01:00
|
|
|
.map(|(name, output)| {
|
|
|
|
(
|
|
|
|
name.clone(),
|
|
|
|
(
|
|
|
|
output.path,
|
|
|
|
Some(
|
|
|
|
NixContextElement::Single {
|
|
|
|
name,
|
2024-01-15 20:32:55 +02:00
|
|
|
derivation: drv_path.to_absolute_path(),
|
2023-12-26 02:03:05 +01:00
|
|
|
}
|
|
|
|
.into(),
|
|
|
|
),
|
|
|
|
)
|
|
|
|
.into(),
|
|
|
|
)
|
|
|
|
})
|
2023-01-23 01:44:24 +03:00
|
|
|
.collect();
|
|
|
|
|
2023-12-26 02:03:05 +01:00
|
|
|
new_attrs.push((
|
|
|
|
"drvPath".to_string(),
|
|
|
|
(
|
2024-01-15 20:32:55 +02:00
|
|
|
drv_path.to_absolute_path(),
|
|
|
|
Some(NixContextElement::Derivation(drv_path.to_absolute_path()).into()),
|
2023-12-26 02:03:05 +01:00
|
|
|
)
|
|
|
|
.into(),
|
|
|
|
));
|
2023-01-23 01:44:24 +03:00
|
|
|
|
|
|
|
Ok(Value::Attrs(Box::new(NixAttrs::from_iter(
|
|
|
|
new_attrs.into_iter(),
|
|
|
|
))))
|
|
|
|
}
|
2023-01-23 16:18:23 +03:00
|
|
|
|
|
|
|
#[builtin("toFile")]
|
2023-12-26 02:03:05 +01:00
|
|
|
async fn builtin_to_file(co: GenCo, name: Value, content: Value) -> Result<Value, ErrorKind> {
|
2023-12-30 03:21:45 +01:00
|
|
|
if name.is_catchable() {
|
|
|
|
return Ok(name);
|
|
|
|
}
|
|
|
|
|
|
|
|
if content.is_catchable() {
|
|
|
|
return Ok(content);
|
|
|
|
}
|
|
|
|
|
2023-01-23 16:18:23 +03:00
|
|
|
let name = name
|
|
|
|
.to_str()
|
|
|
|
.context("evaluating the `name` parameter of builtins.toFile")?;
|
|
|
|
let content = content
|
2023-12-26 01:30:05 +01:00
|
|
|
.to_contextful_str()
|
2023-01-23 16:18:23 +03:00
|
|
|
.context("evaluating the `content` parameter of builtins.toFile")?;
|
|
|
|
|
2023-12-26 01:30:05 +01:00
|
|
|
if content.iter_derivation().count() > 0 || content.iter_single_outputs().count() > 0 {
|
|
|
|
return Err(ErrorKind::UnexpectedContext);
|
|
|
|
}
|
2023-01-23 16:18:23 +03:00
|
|
|
|
2023-12-26 01:30:05 +01:00
|
|
|
let path = nix_compat::store_path::build_text_path(
|
|
|
|
name.as_str(),
|
|
|
|
content.as_str(),
|
|
|
|
content.iter_plain(),
|
|
|
|
)
|
|
|
|
.map_err(|_e| {
|
|
|
|
nix_compat::derivation::DerivationError::InvalidOutputName(name.as_str().to_string())
|
|
|
|
})
|
|
|
|
.map_err(DerivationError::InvalidDerivation)?
|
|
|
|
.to_absolute_path();
|
2023-01-23 16:18:23 +03:00
|
|
|
|
2023-12-26 02:03:05 +01:00
|
|
|
let context: NixContext = NixContextElement::Plain(path.clone()).into();
|
2023-01-23 16:18:23 +03:00
|
|
|
|
|
|
|
// TODO: actually persist the file in the store at that path ...
|
|
|
|
|
2023-12-26 02:03:05 +01:00
|
|
|
Ok(Value::String(NixString::new_context_from(context, &path)))
|
2023-01-23 16:18:23 +03:00
|
|
|
}
|
2023-01-23 01:44:24 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
pub use derivation_builtins::builtins as derivation_builtins;
|