2021-03-01 07:48:01 +02:00
|
|
|
#pragma once
|
2023-04-01 06:18:41 +03:00
|
|
|
///@file
|
2021-03-01 07:48:01 +02:00
|
|
|
|
|
|
|
#include "util.hh"
|
|
|
|
#include "path.hh"
|
2023-01-12 01:57:18 +02:00
|
|
|
#include "outputs-spec.hh"
|
2023-01-29 20:52:38 +02:00
|
|
|
#include "comparator.hh"
|
2021-03-01 07:48:01 +02:00
|
|
|
|
2023-01-29 20:52:38 +02:00
|
|
|
#include <variant>
|
2021-03-01 07:48:01 +02:00
|
|
|
|
|
|
|
#include <nlohmann/json_fwd.hpp>
|
|
|
|
|
|
|
|
namespace nix {
|
|
|
|
|
|
|
|
class Store;
|
|
|
|
|
2021-04-05 17:56:48 +03:00
|
|
|
/**
|
|
|
|
* An opaque derived path.
|
|
|
|
*
|
|
|
|
* Opaque derived paths are just store paths, and fully evaluated. They
|
|
|
|
* cannot be simplified further. Since they are opaque, they cannot be
|
|
|
|
* built, but they can fetched.
|
|
|
|
*/
|
2021-04-05 16:48:18 +03:00
|
|
|
struct DerivedPathOpaque {
|
2021-03-01 07:48:01 +02:00
|
|
|
StorePath path;
|
2021-03-02 05:50:41 +02:00
|
|
|
|
|
|
|
std::string to_string(const Store & store) const;
|
2021-04-05 16:48:18 +03:00
|
|
|
static DerivedPathOpaque parse(const Store & store, std::string_view);
|
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
|
|
|
nlohmann::json toJSON(const Store & store) const;
|
2022-03-28 15:21:35 +03:00
|
|
|
|
2023-01-29 20:52:38 +02:00
|
|
|
GENERATE_CMP(DerivedPathOpaque, me->path);
|
2021-03-01 07:48:01 +02:00
|
|
|
};
|
|
|
|
|
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
|
|
|
struct SingleDerivedPath;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* A single derived path that is built from a derivation
|
|
|
|
*
|
|
|
|
* Built derived paths are pair of a derivation and an output name. They are
|
|
|
|
* evaluated by building the derivation, and then taking the resulting output
|
|
|
|
* path of the given output name.
|
|
|
|
*/
|
|
|
|
struct SingleDerivedPathBuilt {
|
|
|
|
ref<SingleDerivedPath> drvPath;
|
2023-08-25 16:53:12 +03:00
|
|
|
OutputName output;
|
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
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the store path this is ultimately derived from (by realising
|
|
|
|
* and projecting outputs).
|
|
|
|
*
|
|
|
|
* Note that this is *not* a property of the store object being
|
|
|
|
* referred to, but just of this path --- how we happened to be
|
|
|
|
* referring to that store object. In other words, this means this
|
|
|
|
* function breaks "referential transparency". It should therefore
|
|
|
|
* be used only with great care.
|
|
|
|
*/
|
|
|
|
const StorePath & getBaseStorePath() const;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Uses `^` as the separator
|
|
|
|
*/
|
|
|
|
std::string to_string(const Store & store) const;
|
|
|
|
/**
|
|
|
|
* Uses `!` as the separator
|
|
|
|
*/
|
|
|
|
std::string to_string_legacy(const Store & store) const;
|
|
|
|
/**
|
|
|
|
* The caller splits on the separator, so it works for both variants.
|
|
|
|
*
|
|
|
|
* @param xpSettings Stop-gap to avoid globals during unit tests.
|
|
|
|
*/
|
|
|
|
static SingleDerivedPathBuilt parse(
|
|
|
|
const Store & store, ref<SingleDerivedPath> drvPath,
|
2023-08-25 16:53:12 +03:00
|
|
|
OutputNameView outputs,
|
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
|
|
|
const ExperimentalFeatureSettings & xpSettings = experimentalFeatureSettings);
|
|
|
|
nlohmann::json toJSON(Store & store) const;
|
|
|
|
|
|
|
|
DECLARE_CMP(SingleDerivedPathBuilt);
|
|
|
|
};
|
|
|
|
|
|
|
|
using _SingleDerivedPathRaw = std::variant<
|
|
|
|
DerivedPathOpaque,
|
|
|
|
SingleDerivedPathBuilt
|
|
|
|
>;
|
|
|
|
|
2021-04-05 17:56:48 +03:00
|
|
|
/**
|
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
|
|
|
* A "derived path" is a very simple sort of expression (not a Nix
|
|
|
|
* language expression! But an expression in a the general sense) that
|
|
|
|
* evaluates to (concrete) store path. It is either:
|
|
|
|
*
|
|
|
|
* - opaque, in which case it is just a concrete store path with
|
|
|
|
* possibly no known derivation
|
|
|
|
*
|
|
|
|
* - built, in which case it is a pair of a derivation path and an
|
|
|
|
* output name.
|
|
|
|
*/
|
|
|
|
struct SingleDerivedPath : _SingleDerivedPathRaw {
|
|
|
|
using Raw = _SingleDerivedPathRaw;
|
|
|
|
using Raw::Raw;
|
|
|
|
|
|
|
|
using Opaque = DerivedPathOpaque;
|
|
|
|
using Built = SingleDerivedPathBuilt;
|
|
|
|
|
|
|
|
inline const Raw & raw() const {
|
|
|
|
return static_cast<const Raw &>(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the store path this is ultimately derived from (by realising
|
|
|
|
* and projecting outputs).
|
|
|
|
*
|
|
|
|
* Note that this is *not* a property of the store object being
|
|
|
|
* referred to, but just of this path --- how we happened to be
|
|
|
|
* referring to that store object. In other words, this means this
|
|
|
|
* function breaks "referential transparency". It should therefore
|
|
|
|
* be used only with great care.
|
|
|
|
*/
|
|
|
|
const StorePath & getBaseStorePath() const;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Uses `^` as the separator
|
|
|
|
*/
|
|
|
|
std::string to_string(const Store & store) const;
|
|
|
|
/**
|
|
|
|
* Uses `!` as the separator
|
|
|
|
*/
|
|
|
|
std::string to_string_legacy(const Store & store) const;
|
|
|
|
/**
|
|
|
|
* Uses `^` as the separator
|
|
|
|
*
|
|
|
|
* @param xpSettings Stop-gap to avoid globals during unit tests.
|
|
|
|
*/
|
|
|
|
static SingleDerivedPath parse(
|
|
|
|
const Store & store,
|
|
|
|
std::string_view,
|
|
|
|
const ExperimentalFeatureSettings & xpSettings = experimentalFeatureSettings);
|
|
|
|
/**
|
|
|
|
* Uses `!` as the separator
|
|
|
|
*
|
|
|
|
* @param xpSettings Stop-gap to avoid globals during unit tests.
|
|
|
|
*/
|
|
|
|
static SingleDerivedPath parseLegacy(
|
|
|
|
const Store & store,
|
|
|
|
std::string_view,
|
|
|
|
const ExperimentalFeatureSettings & xpSettings = experimentalFeatureSettings);
|
|
|
|
nlohmann::json toJSON(Store & store) const;
|
|
|
|
};
|
|
|
|
|
|
|
|
static inline ref<SingleDerivedPath> makeConstantStorePathRef(StorePath drvPath)
|
|
|
|
{
|
|
|
|
return make_ref<SingleDerivedPath>(SingleDerivedPath::Opaque { drvPath });
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* A set of derived paths that are built from a derivation
|
2021-04-05 17:56:48 +03:00
|
|
|
*
|
|
|
|
* Built derived paths are pair of a derivation and some output names.
|
|
|
|
* They are evaluated by building the derivation, and then replacing the
|
|
|
|
* output names with the resulting outputs.
|
|
|
|
*
|
|
|
|
* Note that does mean a derived store paths evaluates to multiple
|
|
|
|
* opaque paths, which is sort of icky as expressions are supposed to
|
|
|
|
* evaluate to single values. Perhaps this should have just a single
|
|
|
|
* output name.
|
|
|
|
*/
|
2021-04-05 16:48:18 +03:00
|
|
|
struct DerivedPathBuilt {
|
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
|
|
|
ref<SingleDerivedPath> drvPath;
|
2023-01-12 01:57:18 +02:00
|
|
|
OutputsSpec outputs;
|
2021-03-02 05:50:41 +02:00
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Get the store path this is ultimately derived from (by realising
|
|
|
|
* and projecting outputs).
|
|
|
|
*
|
|
|
|
* Note that this is *not* a property of the store object being
|
|
|
|
* referred to, but just of this path --- how we happened to be
|
|
|
|
* referring to that store object. In other words, this means this
|
|
|
|
* function breaks "referential transparency". It should therefore
|
|
|
|
* be used only with great care.
|
|
|
|
*/
|
|
|
|
const StorePath & getBaseStorePath() const;
|
|
|
|
|
2023-04-15 03:45:11 +03:00
|
|
|
/**
|
|
|
|
* Uses `^` as the separator
|
|
|
|
*/
|
|
|
|
std::string to_string(const Store & store) const;
|
|
|
|
/**
|
|
|
|
* Uses `!` as the separator
|
|
|
|
*/
|
|
|
|
std::string to_string_legacy(const Store & store) const;
|
|
|
|
/**
|
|
|
|
* The caller splits on the separator, so it works for both variants.
|
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
|
|
|
*
|
|
|
|
* @param xpSettings Stop-gap to avoid globals during unit tests.
|
2023-04-15 03:45:11 +03:00
|
|
|
*/
|
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
|
|
|
static DerivedPathBuilt parse(
|
|
|
|
const Store & store, ref<SingleDerivedPath>,
|
|
|
|
std::string_view,
|
|
|
|
const ExperimentalFeatureSettings & xpSettings = experimentalFeatureSettings);
|
|
|
|
nlohmann::json toJSON(Store & store) const;
|
2022-03-28 15:21:35 +03:00
|
|
|
|
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
|
|
|
DECLARE_CMP(DerivedPathBuilt);
|
2021-03-01 07:48:01 +02:00
|
|
|
};
|
|
|
|
|
2021-04-05 16:48:18 +03:00
|
|
|
using _DerivedPathRaw = std::variant<
|
|
|
|
DerivedPathOpaque,
|
|
|
|
DerivedPathBuilt
|
2021-03-02 05:50:41 +02:00
|
|
|
>;
|
|
|
|
|
2021-04-05 17:56:48 +03:00
|
|
|
/**
|
|
|
|
* A "derived path" is a very simple sort of expression that evaluates
|
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
|
|
|
* to one or more (concrete) store paths. It is either:
|
2021-04-05 17:56:48 +03:00
|
|
|
*
|
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
|
|
|
* - opaque, in which case it is just a single concrete store path with
|
2021-04-05 17:56:48 +03:00
|
|
|
* possibly no known derivation
|
|
|
|
*
|
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
|
|
|
* - built, in which case it is a pair of a derivation path and some
|
|
|
|
* output names.
|
2021-04-05 17:56:48 +03:00
|
|
|
*/
|
2021-04-05 16:48:18 +03:00
|
|
|
struct DerivedPath : _DerivedPathRaw {
|
|
|
|
using Raw = _DerivedPathRaw;
|
2021-04-05 16:24:42 +03:00
|
|
|
using Raw::Raw;
|
2021-03-02 05:50:41 +02:00
|
|
|
|
2021-04-05 16:48:18 +03:00
|
|
|
using Opaque = DerivedPathOpaque;
|
|
|
|
using Built = DerivedPathBuilt;
|
|
|
|
|
2021-04-05 16:24:42 +03:00
|
|
|
inline const Raw & raw() const {
|
|
|
|
return static_cast<const Raw &>(*this);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Get the store path this is ultimately derived from (by realising
|
|
|
|
* and projecting outputs).
|
|
|
|
*
|
|
|
|
* Note that this is *not* a property of the store object being
|
|
|
|
* referred to, but just of this path --- how we happened to be
|
|
|
|
* referring to that store object. In other words, this means this
|
|
|
|
* function breaks "referential transparency". It should therefore
|
|
|
|
* be used only with great care.
|
|
|
|
*/
|
|
|
|
const StorePath & getBaseStorePath() const;
|
|
|
|
|
2023-04-15 03:45:11 +03:00
|
|
|
/**
|
|
|
|
* Uses `^` as the separator
|
|
|
|
*/
|
|
|
|
std::string to_string(const Store & store) const;
|
|
|
|
/**
|
|
|
|
* Uses `!` as the separator
|
|
|
|
*/
|
|
|
|
std::string to_string_legacy(const Store & store) const;
|
|
|
|
/**
|
|
|
|
* Uses `^` as the separator
|
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
|
|
|
*
|
|
|
|
* @param xpSettings Stop-gap to avoid globals during unit tests.
|
2023-04-15 03:45:11 +03:00
|
|
|
*/
|
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
|
|
|
static DerivedPath parse(
|
|
|
|
const Store & store,
|
|
|
|
std::string_view,
|
|
|
|
const ExperimentalFeatureSettings & xpSettings = experimentalFeatureSettings);
|
2023-04-15 03:45:11 +03:00
|
|
|
/**
|
|
|
|
* Uses `!` as the separator
|
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
|
|
|
*
|
|
|
|
* @param xpSettings Stop-gap to avoid globals during unit tests.
|
2023-04-15 03:45:11 +03:00
|
|
|
*/
|
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
|
|
|
static DerivedPath parseLegacy(
|
|
|
|
const Store & store,
|
|
|
|
std::string_view,
|
|
|
|
const ExperimentalFeatureSettings & xpSettings = experimentalFeatureSettings);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Convert a `SingleDerivedPath` to a `DerivedPath`.
|
|
|
|
*/
|
|
|
|
static DerivedPath fromSingle(const SingleDerivedPath &);
|
|
|
|
|
|
|
|
nlohmann::json toJSON(Store & store) const;
|
2021-04-05 16:24:42 +03:00
|
|
|
};
|
2021-03-02 05:50:41 +02:00
|
|
|
|
2021-05-17 09:45:08 +03:00
|
|
|
typedef std::vector<DerivedPath> DerivedPaths;
|
2021-03-01 07:48:01 +02:00
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Used by various parser functions to require experimental features as
|
|
|
|
* needed.
|
|
|
|
*
|
|
|
|
* Somewhat unfortunate this cannot just be an implementation detail for
|
|
|
|
* this module.
|
|
|
|
*
|
|
|
|
* @param xpSettings Stop-gap to avoid globals during unit tests.
|
|
|
|
*/
|
|
|
|
void drvRequireExperiment(
|
|
|
|
const SingleDerivedPath & drv,
|
|
|
|
const ExperimentalFeatureSettings & xpSettings = experimentalFeatureSettings);
|
2021-03-01 07:48:01 +02:00
|
|
|
}
|