2012-07-18 21:59:03 +03:00
|
|
|
#pragma once
|
2023-04-01 06:18:41 +03:00
|
|
|
///@file
|
2003-06-16 16:33:38 +03:00
|
|
|
|
2020-03-21 17:07:16 +02:00
|
|
|
#include "path.hh"
|
2010-05-13 01:13:09 +03:00
|
|
|
#include "types.hh"
|
2011-07-20 21:10:47 +03:00
|
|
|
#include "hash.hh"
|
2020-06-02 22:44:58 +03:00
|
|
|
#include "content-address.hh"
|
2022-03-18 00:29:15 +02:00
|
|
|
#include "repair-flag.hh"
|
Allow dynamic derivation deps in `inputDrvs`
We use the same nested map representation we used for goals, again in
order to save space. We might someday want to combine with `inputDrvs`,
by doing `V = bool` instead of `V = std::set<OutputName>`, but we are
not doing that yet for sake of a smaller diff.
The ATerm format for Derivations also needs to be extended, in addition
to the in-memory format. To accomodate this, we added a new basic
versioning scheme, so old versions of Nix will get nice errors. (And
going forward, if the ATerm format changes again the errors will be even
better.)
`parsedStrings`, an internal function used as part of parsing
derivations in A-Term format, used to consume the final `]` but expect
the initial `[` to already be consumed. This made for what looked like
unbalanced brackets at callsites, which was confusing. Now it consumes
both which is hopefully less confusing.
As part of testing, we also created a unit test for the A-Term format for
regular non-experimental derivations too.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Apply suggestions from code review
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-10-02 01:05:53 +03:00
|
|
|
#include "derived-path-map.hh"
|
2020-08-22 23:44:47 +03:00
|
|
|
#include "sync.hh"
|
2023-02-18 01:37:35 +02:00
|
|
|
#include "comparator.hh"
|
2023-08-16 19:29:23 +03:00
|
|
|
#include "variant-wrapper.hh"
|
2010-05-13 01:13:09 +03:00
|
|
|
|
2012-09-11 21:45:42 +03:00
|
|
|
#include <map>
|
2020-03-19 06:37:57 +02:00
|
|
|
#include <variant>
|
2012-09-11 21:45:42 +03:00
|
|
|
|
2006-09-05 00:06:23 +03:00
|
|
|
|
|
|
|
namespace nix {
|
2003-06-16 16:33:38 +03:00
|
|
|
|
2022-03-18 17:35:45 +02:00
|
|
|
struct StoreDirConfig;
|
2003-06-16 16:33:38 +03:00
|
|
|
|
2005-01-19 16:36:00 +02:00
|
|
|
/* Abstract syntax of derivations. */
|
* Removed the `id' attribute hack.
* Formalise the notion of fixed-output derivations, i.e., derivations
for which a cryptographic hash of the output is known in advance.
Changes to such derivations should not propagate upwards through the
dependency graph. Previously this was done by specifying the hash
component of the output path through the `id' attribute, but this is
insecure since you can lie about it (i.e., you can specify any hash
and then produce a completely different output). Now the
responsibility for checking the output is moved from the builder to
Nix itself.
A fixed-output derivation can be created by specifying the
`outputHash' and `outputHashAlgo' attributes, the latter taking
values `md5', `sha1', and `sha256', and the former specifying the
actual hash in hexadecimal or in base-32 (auto-detected by looking
at the length of the attribute value). MD5 is included for
compatibility but should be considered deprecated.
* Removed the `drvPath' pseudo-attribute in derivation results. It's
no longer necessary.
* Cleaned up the support for multiple output paths in derivation store
expressions. Each output now has a unique identifier (e.g., `out',
`devel', `docs'). Previously there was no way to tell output paths
apart at the store expression level.
* `nix-hash' now has a flag `--base32' to specify that the hash should
be printed in base-32 notation.
* `fetchurl' accepts parameters `sha256' and `sha1' in addition to
`md5'.
* `nix-prefetch-url' now prints out a SHA-1 hash in base-32. (TODO: a
flag to specify the hash.)
2005-01-17 18:55:19 +02:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
2023-08-16 19:29:23 +03:00
|
|
|
* A single output of a BasicDerivation (and Derivation).
|
2023-03-26 01:12:44 +02:00
|
|
|
*/
|
2023-08-16 19:29:23 +03:00
|
|
|
struct DerivationOutput
|
2020-07-09 02:11:39 +03:00
|
|
|
{
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
2023-08-16 19:29:23 +03:00
|
|
|
* The traditional non-fixed-output derivation type.
|
2023-03-26 01:12:44 +02:00
|
|
|
*/
|
2023-08-16 19:29:23 +03:00
|
|
|
struct InputAddressed
|
|
|
|
{
|
|
|
|
StorePath path;
|
|
|
|
|
|
|
|
GENERATE_CMP(InputAddressed, me->path);
|
|
|
|
};
|
2023-03-26 01:12:44 +02:00
|
|
|
|
|
|
|
/**
|
2023-08-16 19:29:23 +03:00
|
|
|
* Fixed-output derivations, whose output paths are content
|
|
|
|
* addressed according to that fixed output.
|
2023-03-26 01:12:44 +02:00
|
|
|
*/
|
2023-08-16 19:29:23 +03:00
|
|
|
struct CAFixed
|
|
|
|
{
|
|
|
|
/**
|
|
|
|
* Method and hash used for expected hash computation.
|
|
|
|
*
|
|
|
|
* References are not allowed by fiat.
|
|
|
|
*/
|
|
|
|
ContentAddress ca;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Return the \ref StorePath "store path" corresponding to this output
|
|
|
|
*
|
|
|
|
* @param drvName The name of the derivation this is an output of, without the `.drv`.
|
|
|
|
* @param outputName The name of this output.
|
|
|
|
*/
|
2022-03-18 17:35:45 +02:00
|
|
|
StorePath path(const StoreDirConfig & store, std::string_view drvName, OutputNameView outputName) const;
|
2023-08-16 19:29:23 +03:00
|
|
|
|
|
|
|
GENERATE_CMP(CAFixed, me->ca);
|
|
|
|
};
|
2023-02-18 01:37:35 +02:00
|
|
|
|
2023-08-16 19:29:23 +03:00
|
|
|
/**
|
|
|
|
* Floating-output derivations, whose output paths are content
|
|
|
|
* addressed, but not fixed, and so are dynamically calculated from
|
|
|
|
* whatever the output ends up being.
|
|
|
|
* */
|
|
|
|
struct CAFloating
|
|
|
|
{
|
|
|
|
/**
|
|
|
|
* How the file system objects will be serialized for hashing
|
|
|
|
*/
|
|
|
|
ContentAddressMethod method;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* How the serialization will be hashed
|
|
|
|
*/
|
2023-11-28 15:20:27 +02:00
|
|
|
HashAlgorithm hashAlgo;
|
2023-08-16 19:29:23 +03:00
|
|
|
|
2023-11-28 15:20:27 +02:00
|
|
|
GENERATE_CMP(CAFloating, me->method, me->hashAlgo);
|
2023-08-16 19:29:23 +03:00
|
|
|
};
|
2020-07-09 02:11:39 +03:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
2023-08-16 19:29:23 +03:00
|
|
|
* Input-addressed output which depends on a (CA) derivation whose hash
|
|
|
|
* isn't known yet.
|
2023-03-26 01:12:44 +02:00
|
|
|
*/
|
2023-08-16 19:29:23 +03:00
|
|
|
struct Deferred {
|
|
|
|
GENERATE_CMP(Deferred);
|
|
|
|
};
|
2023-03-26 01:12:44 +02:00
|
|
|
|
|
|
|
/**
|
2023-08-16 19:29:23 +03:00
|
|
|
* Impure output which is moved to a content-addressed location (like
|
|
|
|
* CAFloating) but isn't registered as a realization.
|
2023-03-26 01:12:44 +02:00
|
|
|
*/
|
2023-08-16 19:29:23 +03:00
|
|
|
struct Impure
|
|
|
|
{
|
|
|
|
/**
|
|
|
|
* How the file system objects will be serialized for hashing
|
|
|
|
*/
|
|
|
|
ContentAddressMethod method;
|
2023-02-18 01:37:35 +02:00
|
|
|
|
2023-08-16 19:29:23 +03:00
|
|
|
/**
|
|
|
|
* How the serialization will be hashed
|
|
|
|
*/
|
2023-11-28 15:20:27 +02:00
|
|
|
HashAlgorithm hashAlgo;
|
2020-07-12 19:12:21 +03:00
|
|
|
|
2023-11-28 15:20:27 +02:00
|
|
|
GENERATE_CMP(Impure, me->method, me->hashAlgo);
|
2023-08-16 19:29:23 +03:00
|
|
|
};
|
2020-09-23 17:30:42 +03:00
|
|
|
|
2023-08-16 19:29:23 +03:00
|
|
|
typedef std::variant<
|
|
|
|
InputAddressed,
|
|
|
|
CAFixed,
|
|
|
|
CAFloating,
|
|
|
|
Deferred,
|
|
|
|
Impure
|
|
|
|
> Raw;
|
2023-02-18 01:37:35 +02:00
|
|
|
|
2023-08-16 19:29:23 +03:00
|
|
|
Raw raw;
|
2022-03-30 17:31:01 +03:00
|
|
|
|
2023-08-16 19:29:23 +03:00
|
|
|
GENERATE_CMP(DerivationOutput, me->raw);
|
2022-03-18 00:29:15 +02:00
|
|
|
|
2023-08-16 19:29:23 +03:00
|
|
|
MAKE_WRAPPER_CONSTRUCTOR(DerivationOutput);
|
2022-03-18 00:29:15 +02:00
|
|
|
|
2023-08-16 19:29:23 +03:00
|
|
|
/**
|
|
|
|
* Force choosing a variant
|
|
|
|
*/
|
|
|
|
DerivationOutput() = delete;
|
2021-03-17 12:27:11 +02:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* \note when you use this function you should make sure that you're
|
|
|
|
* passing the right derivation name. When in doubt, you should use
|
|
|
|
* the safer interface provided by
|
|
|
|
* BasicDerivation::outputsAndOptPaths
|
|
|
|
*/
|
2022-03-18 17:35:45 +02:00
|
|
|
std::optional<StorePath> path(const StoreDirConfig & store, std::string_view drvName, OutputNameView outputName) const;
|
2022-03-18 00:29:15 +02:00
|
|
|
|
2023-02-18 01:37:35 +02:00
|
|
|
nlohmann::json toJSON(
|
2022-03-18 17:35:45 +02:00
|
|
|
const StoreDirConfig & store,
|
2023-02-18 01:37:35 +02:00
|
|
|
std::string_view drvName,
|
2023-08-25 16:53:12 +03:00
|
|
|
OutputNameView outputName) const;
|
2023-04-17 18:22:31 +03:00
|
|
|
/**
|
|
|
|
* @param xpSettings Stop-gap to avoid globals during unit tests.
|
|
|
|
*/
|
2023-02-18 01:37:35 +02:00
|
|
|
static DerivationOutput fromJSON(
|
2022-03-18 17:35:45 +02:00
|
|
|
const StoreDirConfig & store,
|
2023-02-18 01:37:35 +02:00
|
|
|
std::string_view drvName,
|
2023-08-25 16:53:12 +03:00
|
|
|
OutputNameView outputName,
|
2023-04-17 18:22:31 +03:00
|
|
|
const nlohmann::json & json,
|
|
|
|
const ExperimentalFeatureSettings & xpSettings = experimentalFeatureSettings);
|
* Removed the `id' attribute hack.
* Formalise the notion of fixed-output derivations, i.e., derivations
for which a cryptographic hash of the output is known in advance.
Changes to such derivations should not propagate upwards through the
dependency graph. Previously this was done by specifying the hash
component of the output path through the `id' attribute, but this is
insecure since you can lie about it (i.e., you can specify any hash
and then produce a completely different output). Now the
responsibility for checking the output is moved from the builder to
Nix itself.
A fixed-output derivation can be created by specifying the
`outputHash' and `outputHashAlgo' attributes, the latter taking
values `md5', `sha1', and `sha256', and the former specifying the
actual hash in hexadecimal or in base-32 (auto-detected by looking
at the length of the attribute value). MD5 is included for
compatibility but should be considered deprecated.
* Removed the `drvPath' pseudo-attribute in derivation results. It's
no longer necessary.
* Cleaned up the support for multiple output paths in derivation store
expressions. Each output now has a unique identifier (e.g., `out',
`devel', `docs'). Previously there was no way to tell output paths
apart at the store expression level.
* `nix-hash' now has a flag `--base32' to specify that the hash should
be printed in base-32 notation.
* `fetchurl' accepts parameters `sha256' and `sha1' in addition to
`md5'.
* `nix-prefetch-url' now prints out a SHA-1 hash in base-32. (TODO: a
flag to specify the hash.)
2005-01-17 18:55:19 +02:00
|
|
|
};
|
|
|
|
|
2022-02-25 17:00:00 +02:00
|
|
|
typedef std::map<std::string, DerivationOutput> DerivationOutputs;
|
2005-01-20 16:10:19 +02:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* These are analogues to the previous DerivationOutputs data type,
|
|
|
|
* but they also contains, for each output, the (optional) store
|
|
|
|
* path in which it would be written. To calculate values of these
|
|
|
|
* types, see the corresponding functions in BasicDerivation.
|
|
|
|
*/
|
2022-02-25 17:00:00 +02:00
|
|
|
typedef std::map<std::string, std::pair<DerivationOutput, std::optional<StorePath>>>
|
2020-07-27 23:42:02 +03:00
|
|
|
DerivationOutputsAndOptPaths;
|
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* For inputs that are sub-derivations, we specify exactly which
|
|
|
|
* output IDs we are interested in.
|
|
|
|
*/
|
2019-12-05 20:11:09 +02:00
|
|
|
typedef std::map<StorePath, StringSet> DerivationInputs;
|
2005-01-20 16:10:19 +02:00
|
|
|
|
2023-08-16 19:29:23 +03:00
|
|
|
struct DerivationType {
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
2023-08-16 19:29:23 +03:00
|
|
|
* Input-addressed derivation types
|
|
|
|
*/
|
|
|
|
struct InputAddressed {
|
|
|
|
/**
|
|
|
|
* True iff the derivation type can't be determined statically,
|
|
|
|
* for instance because it (transitively) depends on a content-addressed
|
|
|
|
* derivation.
|
|
|
|
*/
|
|
|
|
bool deferred;
|
|
|
|
|
|
|
|
GENERATE_CMP(InputAddressed, me->deferred);
|
|
|
|
};
|
2020-03-15 08:23:17 +02:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
2023-08-16 19:29:23 +03:00
|
|
|
* Content-addressed derivation types
|
2023-03-26 01:12:44 +02:00
|
|
|
*/
|
2023-08-16 19:29:23 +03:00
|
|
|
struct ContentAddressed {
|
|
|
|
/**
|
|
|
|
* Whether the derivation should be built safely inside a sandbox.
|
|
|
|
*/
|
|
|
|
bool sandboxed;
|
|
|
|
/**
|
|
|
|
* Whether the derivation's outputs' content-addresses are "fixed"
|
|
|
|
* or "floating".
|
|
|
|
*
|
|
|
|
* - Fixed: content-addresses are written down as part of the
|
|
|
|
* derivation itself. If the outputs don't end up matching the
|
|
|
|
* build fails.
|
|
|
|
*
|
|
|
|
* - Floating: content-addresses are not written down, we do not
|
|
|
|
* know them until we perform the build.
|
|
|
|
*/
|
|
|
|
bool fixed;
|
|
|
|
|
|
|
|
GENERATE_CMP(ContentAddressed, me->sandboxed, me->fixed);
|
|
|
|
};
|
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
2023-08-16 19:29:23 +03:00
|
|
|
* Impure derivation type
|
2023-03-26 01:12:44 +02:00
|
|
|
*
|
2023-08-16 19:29:23 +03:00
|
|
|
* This is similar at buil-time to the content addressed, not standboxed, not fixed
|
|
|
|
* type, but has some restrictions on its usage.
|
2023-03-26 01:12:44 +02:00
|
|
|
*/
|
2023-08-16 19:29:23 +03:00
|
|
|
struct Impure {
|
|
|
|
GENERATE_CMP(Impure);
|
|
|
|
};
|
2020-06-03 20:38:54 +03:00
|
|
|
|
2023-08-16 19:29:23 +03:00
|
|
|
typedef std::variant<
|
|
|
|
InputAddressed,
|
|
|
|
ContentAddressed,
|
|
|
|
Impure
|
|
|
|
> Raw;
|
|
|
|
|
|
|
|
Raw raw;
|
|
|
|
|
|
|
|
GENERATE_CMP(DerivationType, me->raw);
|
2022-03-30 17:31:01 +03:00
|
|
|
|
2023-08-16 19:29:23 +03:00
|
|
|
MAKE_WRAPPER_CONSTRUCTOR(DerivationType);
|
2020-06-03 20:38:54 +03:00
|
|
|
|
2023-08-16 19:29:23 +03:00
|
|
|
/**
|
|
|
|
* Force choosing a variant
|
|
|
|
*/
|
|
|
|
DerivationType() = delete;
|
2022-03-18 02:36:52 +02:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Do the outputs of the derivation have paths calculated from their
|
|
|
|
* content, or from the derivation itself?
|
|
|
|
*/
|
2022-03-18 02:36:52 +02:00
|
|
|
bool isCA() const;
|
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Is the content of the outputs fixed <em>a priori</em> via a hash?
|
|
|
|
* Never true for non-CA derivations.
|
|
|
|
*/
|
2022-03-18 02:36:52 +02:00
|
|
|
bool isFixed() const;
|
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Whether the derivation is fully sandboxed. If false, the sandbox
|
|
|
|
* is opened up, e.g. the derivation has access to the network. Note
|
|
|
|
* that whether or not we actually sandbox the derivation is
|
|
|
|
* controlled separately. Always true for non-CA derivations.
|
|
|
|
*/
|
2022-03-31 17:06:40 +03:00
|
|
|
bool isSandboxed() const;
|
2022-03-30 17:31:01 +03:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Whether the derivation is expected to produce the same result
|
|
|
|
* every time, and therefore it only needs to be built once. This is
|
|
|
|
* only false for derivations that have the attribute '__impure =
|
|
|
|
* true'.
|
|
|
|
*/
|
2022-03-30 17:31:01 +03:00
|
|
|
bool isPure() const;
|
2022-03-18 02:36:52 +02:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Does the derivation knows its own output paths?
|
|
|
|
* Only true when there's no floating-ca derivation involved in the
|
|
|
|
* closure, or if fixed output.
|
2022-03-18 02:36:52 +02:00
|
|
|
*/
|
|
|
|
bool hasKnownOutputPaths() const;
|
|
|
|
};
|
2021-02-26 17:34:33 +02:00
|
|
|
|
Allow remote builds without sending the derivation closure
Previously, to build a derivation remotely, we had to copy the entire
closure of the .drv file to the remote machine, even though we only
need the top-level derivation. This is very wasteful: the closure can
contain thousands of store paths, and in some Hydra use cases, include
source paths that are very large (e.g. Git/Mercurial checkouts).
So now there is a new operation, StoreAPI::buildDerivation(), that
performs a build from an in-memory representation of a derivation
(BasicDerivation) rather than from a on-disk .drv file. The only files
that need to be in the Nix store are the sources of the derivation
(drv.inputSrcs), and the needed output paths of the dependencies (as
described by drv.inputDrvs). "nix-store --serve" exposes this
interface.
Note that this is a privileged operation, because you can construct a
derivation that builds any store path whatsoever. Fixing this will
require changing the hashing scheme (i.e., the output paths should be
computed from the other fields in BasicDerivation, allowing them to be
verified without access to other derivations). However, this would be
quite nice because it would allow .drv-free building (e.g. "nix-env
-i" wouldn't have to write any .drv files to disk).
Fixes #173.
2015-07-17 18:57:40 +03:00
|
|
|
struct BasicDerivation
|
2003-07-20 22:29:38 +03:00
|
|
|
{
|
2023-04-07 16:55:28 +03:00
|
|
|
/**
|
|
|
|
* keyed on symbolic IDs
|
|
|
|
*/
|
|
|
|
DerivationOutputs outputs;
|
|
|
|
/**
|
|
|
|
* inputs that are sources
|
|
|
|
*/
|
|
|
|
StorePathSet inputSrcs;
|
2022-02-25 17:00:00 +02:00
|
|
|
std::string platform;
|
2003-10-08 18:06:59 +03:00
|
|
|
Path builder;
|
2003-08-15 15:32:37 +03:00
|
|
|
Strings args;
|
2003-07-20 22:29:38 +03:00
|
|
|
StringPairs env;
|
2020-07-12 18:02:36 +03:00
|
|
|
std::string name;
|
Allow remote builds without sending the derivation closure
Previously, to build a derivation remotely, we had to copy the entire
closure of the .drv file to the remote machine, even though we only
need the top-level derivation. This is very wasteful: the closure can
contain thousands of store paths, and in some Hydra use cases, include
source paths that are very large (e.g. Git/Mercurial checkouts).
So now there is a new operation, StoreAPI::buildDerivation(), that
performs a build from an in-memory representation of a derivation
(BasicDerivation) rather than from a on-disk .drv file. The only files
that need to be in the Nix store are the sources of the derivation
(drv.inputSrcs), and the needed output paths of the dependencies (as
described by drv.inputDrvs). "nix-store --serve" exposes this
interface.
Note that this is a privileged operation, because you can construct a
derivation that builds any store path whatsoever. Fixing this will
require changing the hashing scheme (i.e., the output paths should be
computed from the other fields in BasicDerivation, allowing them to be
verified without access to other derivations). However, this would be
quite nice because it would allow .drv-free building (e.g. "nix-env
-i" wouldn't have to write any .drv files to disk).
Fixes #173.
2015-07-17 18:57:40 +03:00
|
|
|
|
2020-08-23 18:27:30 +03:00
|
|
|
BasicDerivation() = default;
|
Allow remote builds without sending the derivation closure
Previously, to build a derivation remotely, we had to copy the entire
closure of the .drv file to the remote machine, even though we only
need the top-level derivation. This is very wasteful: the closure can
contain thousands of store paths, and in some Hydra use cases, include
source paths that are very large (e.g. Git/Mercurial checkouts).
So now there is a new operation, StoreAPI::buildDerivation(), that
performs a build from an in-memory representation of a derivation
(BasicDerivation) rather than from a on-disk .drv file. The only files
that need to be in the Nix store are the sources of the derivation
(drv.inputSrcs), and the needed output paths of the dependencies (as
described by drv.inputDrvs). "nix-store --serve" exposes this
interface.
Note that this is a privileged operation, because you can construct a
derivation that builds any store path whatsoever. Fixing this will
require changing the hashing scheme (i.e., the output paths should be
computed from the other fields in BasicDerivation, allowing them to be
verified without access to other derivations). However, this would be
quite nice because it would allow .drv-free building (e.g. "nix-env
-i" wouldn't have to write any .drv files to disk).
Fixes #173.
2015-07-17 18:57:40 +03:00
|
|
|
virtual ~BasicDerivation() { };
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 15:28:26 +02:00
|
|
|
|
|
|
|
bool isBuiltin() const;
|
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Return true iff this is a fixed-output derivation.
|
|
|
|
*/
|
2020-03-15 08:23:17 +02:00
|
|
|
DerivationType type() const;
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 15:28:26 +02:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Return the output names of a derivation.
|
|
|
|
*/
|
2020-06-12 13:46:33 +03:00
|
|
|
StringSet outputNames() const;
|
2020-07-12 18:26:30 +03:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Calculates the maps that contains all the DerivationOutputs, but
|
|
|
|
* augmented with knowledge of the Store paths they would be written
|
|
|
|
* into.
|
|
|
|
*/
|
2022-03-18 17:35:45 +02:00
|
|
|
DerivationOutputsAndOptPaths outputsAndOptPaths(const StoreDirConfig & store) const;
|
2020-07-27 23:42:02 +03:00
|
|
|
|
2020-07-12 18:26:30 +03:00
|
|
|
static std::string_view nameFromPath(const StorePath & storePath);
|
2023-02-18 01:37:35 +02:00
|
|
|
|
|
|
|
GENERATE_CMP(BasicDerivation,
|
|
|
|
me->outputs,
|
|
|
|
me->inputSrcs,
|
|
|
|
me->platform,
|
|
|
|
me->builder,
|
|
|
|
me->args,
|
|
|
|
me->env,
|
|
|
|
me->name);
|
Allow remote builds without sending the derivation closure
Previously, to build a derivation remotely, we had to copy the entire
closure of the .drv file to the remote machine, even though we only
need the top-level derivation. This is very wasteful: the closure can
contain thousands of store paths, and in some Hydra use cases, include
source paths that are very large (e.g. Git/Mercurial checkouts).
So now there is a new operation, StoreAPI::buildDerivation(), that
performs a build from an in-memory representation of a derivation
(BasicDerivation) rather than from a on-disk .drv file. The only files
that need to be in the Nix store are the sources of the derivation
(drv.inputSrcs), and the needed output paths of the dependencies (as
described by drv.inputDrvs). "nix-store --serve" exposes this
interface.
Note that this is a privileged operation, because you can construct a
derivation that builds any store path whatsoever. Fixing this will
require changing the hashing scheme (i.e., the output paths should be
computed from the other fields in BasicDerivation, allowing them to be
verified without access to other derivations). However, this would be
quite nice because it would allow .drv-free building (e.g. "nix-env
-i" wouldn't have to write any .drv files to disk).
Fixes #173.
2015-07-17 18:57:40 +03:00
|
|
|
};
|
|
|
|
|
2022-03-18 17:35:45 +02:00
|
|
|
class Store;
|
|
|
|
|
Allow remote builds without sending the derivation closure
Previously, to build a derivation remotely, we had to copy the entire
closure of the .drv file to the remote machine, even though we only
need the top-level derivation. This is very wasteful: the closure can
contain thousands of store paths, and in some Hydra use cases, include
source paths that are very large (e.g. Git/Mercurial checkouts).
So now there is a new operation, StoreAPI::buildDerivation(), that
performs a build from an in-memory representation of a derivation
(BasicDerivation) rather than from a on-disk .drv file. The only files
that need to be in the Nix store are the sources of the derivation
(drv.inputSrcs), and the needed output paths of the dependencies (as
described by drv.inputDrvs). "nix-store --serve" exposes this
interface.
Note that this is a privileged operation, because you can construct a
derivation that builds any store path whatsoever. Fixing this will
require changing the hashing scheme (i.e., the output paths should be
computed from the other fields in BasicDerivation, allowing them to be
verified without access to other derivations). However, this would be
quite nice because it would allow .drv-free building (e.g. "nix-env
-i" wouldn't have to write any .drv files to disk).
Fixes #173.
2015-07-17 18:57:40 +03:00
|
|
|
struct Derivation : BasicDerivation
|
|
|
|
{
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* inputs that are sub-derivations
|
|
|
|
*/
|
Allow dynamic derivation deps in `inputDrvs`
We use the same nested map representation we used for goals, again in
order to save space. We might someday want to combine with `inputDrvs`,
by doing `V = bool` instead of `V = std::set<OutputName>`, but we are
not doing that yet for sake of a smaller diff.
The ATerm format for Derivations also needs to be extended, in addition
to the in-memory format. To accomodate this, we added a new basic
versioning scheme, so old versions of Nix will get nice errors. (And
going forward, if the ATerm format changes again the errors will be even
better.)
`parsedStrings`, an internal function used as part of parsing
derivations in A-Term format, used to consume the final `]` but expect
the initial `[` to already be consumed. This made for what looked like
unbalanced brackets at callsites, which was confusing. Now it consumes
both which is hopefully less confusing.
As part of testing, we also created a unit test for the A-Term format for
regular non-experimental derivations too.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Apply suggestions from code review
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-10-02 01:05:53 +03:00
|
|
|
DerivedPathMap<std::set<OutputName>> inputDrvs;
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 15:28:26 +02:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Print a derivation.
|
|
|
|
*/
|
2022-03-18 17:35:45 +02:00
|
|
|
std::string unparse(const StoreDirConfig & store, bool maskOutputs,
|
Allow dynamic derivation deps in `inputDrvs`
We use the same nested map representation we used for goals, again in
order to save space. We might someday want to combine with `inputDrvs`,
by doing `V = bool` instead of `V = std::set<OutputName>`, but we are
not doing that yet for sake of a smaller diff.
The ATerm format for Derivations also needs to be extended, in addition
to the in-memory format. To accomodate this, we added a new basic
versioning scheme, so old versions of Nix will get nice errors. (And
going forward, if the ATerm format changes again the errors will be even
better.)
`parsedStrings`, an internal function used as part of parsing
derivations in A-Term format, used to consume the final `]` but expect
the initial `[` to already be consumed. This made for what looked like
unbalanced brackets at callsites, which was confusing. Now it consumes
both which is hopefully less confusing.
As part of testing, we also created a unit test for the A-Term format for
regular non-experimental derivations too.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Apply suggestions from code review
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-10-02 01:05:53 +03:00
|
|
|
DerivedPathMap<StringSet>::ChildNode::Map * actualInputs = nullptr) const;
|
2019-12-05 20:11:09 +02:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Return the underlying basic derivation but with these changes:
|
|
|
|
*
|
|
|
|
* 1. Input drvs are emptied, but the outputs of them that were used
|
|
|
|
* are added directly to input sources.
|
|
|
|
*
|
|
|
|
* 2. Input placeholders are replaced with realized input store
|
|
|
|
* paths.
|
|
|
|
*/
|
2022-03-30 17:31:01 +03:00
|
|
|
std::optional<BasicDerivation> tryResolve(Store & store) const;
|
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Like the above, but instead of querying the Nix database for
|
|
|
|
* realisations, uses a given mapping from input derivation paths +
|
|
|
|
* output names to actual output store paths.
|
|
|
|
*/
|
2022-03-30 17:31:01 +03:00
|
|
|
std::optional<BasicDerivation> tryResolve(
|
|
|
|
Store & store,
|
|
|
|
const std::map<std::pair<StorePath, std::string>, StorePath> & inputDrvOutputs) const;
|
2020-08-22 23:44:47 +03:00
|
|
|
|
2023-04-18 02:02:45 +03:00
|
|
|
/**
|
|
|
|
* Check that the derivation is valid and does not present any
|
|
|
|
* illegal states.
|
|
|
|
*
|
|
|
|
* This is mainly a matter of checking the outputs, where our C++
|
|
|
|
* representation supports all sorts of combinations we do not yet
|
|
|
|
* allow.
|
|
|
|
*/
|
2023-03-01 23:57:36 +02:00
|
|
|
void checkInvariants(Store & store, const StorePath & drvPath) const;
|
|
|
|
|
2020-08-23 18:27:30 +03:00
|
|
|
Derivation() = default;
|
2020-09-09 22:13:21 +03:00
|
|
|
Derivation(const BasicDerivation & bd) : BasicDerivation(bd) { }
|
2020-08-23 18:27:30 +03:00
|
|
|
Derivation(BasicDerivation && bd) : BasicDerivation(std::move(bd)) { }
|
2023-02-18 01:37:35 +02:00
|
|
|
|
2022-03-18 17:35:45 +02:00
|
|
|
nlohmann::json toJSON(const StoreDirConfig & store) const;
|
2023-02-18 01:37:35 +02:00
|
|
|
static Derivation fromJSON(
|
2022-03-18 17:35:45 +02:00
|
|
|
const StoreDirConfig & store,
|
Allow dynamic derivation deps in `inputDrvs`
We use the same nested map representation we used for goals, again in
order to save space. We might someday want to combine with `inputDrvs`,
by doing `V = bool` instead of `V = std::set<OutputName>`, but we are
not doing that yet for sake of a smaller diff.
The ATerm format for Derivations also needs to be extended, in addition
to the in-memory format. To accomodate this, we added a new basic
versioning scheme, so old versions of Nix will get nice errors. (And
going forward, if the ATerm format changes again the errors will be even
better.)
`parsedStrings`, an internal function used as part of parsing
derivations in A-Term format, used to consume the final `]` but expect
the initial `[` to already be consumed. This made for what looked like
unbalanced brackets at callsites, which was confusing. Now it consumes
both which is hopefully less confusing.
As part of testing, we also created a unit test for the A-Term format for
regular non-experimental derivations too.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Apply suggestions from code review
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-10-02 01:05:53 +03:00
|
|
|
const nlohmann::json & json,
|
|
|
|
const ExperimentalFeatureSettings & xpSettings = experimentalFeatureSettings);
|
2023-02-18 01:37:35 +02:00
|
|
|
|
|
|
|
GENERATE_CMP(Derivation,
|
|
|
|
static_cast<const BasicDerivation &>(*me),
|
|
|
|
me->inputDrvs);
|
2003-07-20 22:29:38 +03:00
|
|
|
};
|
|
|
|
|
2003-07-15 19:28:54 +03:00
|
|
|
|
2016-02-04 15:48:42 +02:00
|
|
|
class Store;
|
2011-09-01 00:11:50 +03:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Write a derivation to the Nix store, and return its path.
|
|
|
|
*/
|
2020-08-23 18:00:25 +03:00
|
|
|
StorePath writeDerivation(Store & store,
|
2020-09-04 21:33:58 +03:00
|
|
|
const Derivation & drv,
|
|
|
|
RepairFlag repair = NoRepair,
|
|
|
|
bool readOnly = false);
|
2003-07-10 21:48:11 +03:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Read a derivation from a file.
|
|
|
|
*/
|
Allow dynamic derivation deps in `inputDrvs`
We use the same nested map representation we used for goals, again in
order to save space. We might someday want to combine with `inputDrvs`,
by doing `V = bool` instead of `V = std::set<OutputName>`, but we are
not doing that yet for sake of a smaller diff.
The ATerm format for Derivations also needs to be extended, in addition
to the in-memory format. To accomodate this, we added a new basic
versioning scheme, so old versions of Nix will get nice errors. (And
going forward, if the ATerm format changes again the errors will be even
better.)
`parsedStrings`, an internal function used as part of parsing
derivations in A-Term format, used to consume the final `]` but expect
the initial `[` to already be consumed. This made for what looked like
unbalanced brackets at callsites, which was confusing. Now it consumes
both which is hopefully less confusing.
As part of testing, we also created a unit test for the A-Term format for
regular non-experimental derivations too.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Apply suggestions from code review
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-10-02 01:05:53 +03:00
|
|
|
Derivation parseDerivation(
|
2022-03-18 17:35:45 +02:00
|
|
|
const StoreDirConfig & store,
|
Allow dynamic derivation deps in `inputDrvs`
We use the same nested map representation we used for goals, again in
order to save space. We might someday want to combine with `inputDrvs`,
by doing `V = bool` instead of `V = std::set<OutputName>`, but we are
not doing that yet for sake of a smaller diff.
The ATerm format for Derivations also needs to be extended, in addition
to the in-memory format. To accomodate this, we added a new basic
versioning scheme, so old versions of Nix will get nice errors. (And
going forward, if the ATerm format changes again the errors will be even
better.)
`parsedStrings`, an internal function used as part of parsing
derivations in A-Term format, used to consume the final `]` but expect
the initial `[` to already be consumed. This made for what looked like
unbalanced brackets at callsites, which was confusing. Now it consumes
both which is hopefully less confusing.
As part of testing, we also created a unit test for the A-Term format for
regular non-experimental derivations too.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Apply suggestions from code review
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-10-02 01:05:53 +03:00
|
|
|
std::string && s,
|
|
|
|
std::string_view name,
|
|
|
|
const ExperimentalFeatureSettings & xpSettings = experimentalFeatureSettings);
|
2003-07-16 14:05:59 +03:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* \todo Remove.
|
|
|
|
*
|
|
|
|
* Use Path::isDerivation instead.
|
|
|
|
*/
|
2022-12-07 13:58:58 +02:00
|
|
|
bool isDerivation(std::string_view fileName);
|
2005-01-19 16:36:00 +02:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Calculate the name that will be used for the store path for this
|
|
|
|
* output.
|
|
|
|
*
|
|
|
|
* This is usually <drv-name>-<output-name>, but is just <drv-name> when
|
|
|
|
* the output name is "out".
|
|
|
|
*/
|
2023-08-25 16:53:12 +03:00
|
|
|
std::string outputPathName(std::string_view drvName, OutputNameView outputName);
|
2020-08-07 22:09:26 +03:00
|
|
|
|
2020-06-21 19:43:17 +03:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* The hashes modulo of a derivation.
|
|
|
|
*
|
|
|
|
* Each output is given a hash, although in practice only the content-addressed
|
|
|
|
* derivations (fixed-output or not) will have a different hash for each
|
|
|
|
* output.
|
|
|
|
*/
|
2021-10-01 21:05:53 +03:00
|
|
|
struct DrvHash {
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Map from output names to hashes
|
|
|
|
*/
|
2022-03-16 15:21:09 +02:00
|
|
|
std::map<std::string, Hash> hashes;
|
2021-10-01 21:05:53 +03:00
|
|
|
|
2022-03-30 17:31:01 +03:00
|
|
|
enum struct Kind : bool {
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Statically determined derivations.
|
|
|
|
* This hash will be directly used to compute the output paths
|
|
|
|
*/
|
2021-10-01 21:05:53 +03:00
|
|
|
Regular,
|
2023-03-26 01:12:44 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Floating-output derivations (and their reverse dependencies).
|
|
|
|
*/
|
2021-10-01 21:05:53 +03:00
|
|
|
Deferred,
|
|
|
|
};
|
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* The kind of derivation this is, simplified for just "derivation hash
|
|
|
|
* modulo" purposes.
|
|
|
|
*/
|
2021-10-01 21:05:53 +03:00
|
|
|
Kind kind;
|
|
|
|
};
|
|
|
|
|
|
|
|
void operator |= (DrvHash::Kind & self, const DrvHash::Kind & other) noexcept;
|
2020-09-23 17:30:42 +03:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Returns hashes with the details of fixed-output subderivations
|
|
|
|
* expunged.
|
|
|
|
*
|
|
|
|
* A fixed-output derivation is a derivation whose outputs have a
|
|
|
|
* specified content hash and hash algorithm. (Currently they must have
|
2023-04-07 16:55:28 +03:00
|
|
|
* exactly one output (`out`), which is specified using the `outputHash`
|
|
|
|
* and `outputHashAlgo` attributes, but the algorithm doesn't assume
|
2023-03-26 01:12:44 +02:00
|
|
|
* this.) We don't want changes to such derivations to propagate upwards
|
|
|
|
* through the dependency graph, changing output paths everywhere.
|
|
|
|
*
|
2023-04-07 16:55:28 +03:00
|
|
|
* For instance, if we change the url in a call to the `fetchurl`
|
2023-03-26 01:12:44 +02:00
|
|
|
* function, we do not want to rebuild everything depending on it---after
|
|
|
|
* all, (the hash of) the file being downloaded is unchanged. So the
|
|
|
|
* *output paths* should not change. On the other hand, the *derivation
|
|
|
|
* paths* should change to reflect the new dependency graph.
|
|
|
|
*
|
|
|
|
* For fixed-output derivations, this returns a map from the name of
|
|
|
|
* each output to its hash, unique up to the output's contents.
|
|
|
|
*
|
|
|
|
* For regular derivations, it returns a single hash of the derivation
|
|
|
|
* ATerm, after subderivations have been likewise expunged from that
|
|
|
|
* derivation.
|
2020-03-19 06:37:57 +02:00
|
|
|
*/
|
2022-03-16 15:21:09 +02:00
|
|
|
DrvHash hashDerivationModulo(Store & store, const Derivation & drv, bool maskOutputs);
|
2011-07-20 21:10:47 +03:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Return a map associating each output to a hash that uniquely identifies its
|
|
|
|
* derivation (modulo the self-references).
|
|
|
|
*
|
|
|
|
* \todo What is the Hash in this map?
|
2020-12-09 17:56:56 +02:00
|
|
|
*/
|
2022-03-30 17:31:01 +03:00
|
|
|
std::map<std::string, Hash> staticOutputHashes(Store & store, const Derivation & drv);
|
2020-12-09 17:56:56 +02:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* Memoisation of hashDerivationModulo().
|
|
|
|
*/
|
2022-03-16 15:21:09 +02:00
|
|
|
typedef std::map<StorePath, DrvHash> DrvHashes;
|
2011-07-20 21:10:47 +03:00
|
|
|
|
2020-08-22 23:44:47 +03:00
|
|
|
// FIXME: global, though at least thread-safe.
|
2020-11-19 18:50:06 +02:00
|
|
|
extern Sync<DrvHashes> drvHashes;
|
2020-08-22 23:44:47 +03:00
|
|
|
|
Allow remote builds without sending the derivation closure
Previously, to build a derivation remotely, we had to copy the entire
closure of the .drv file to the remote machine, even though we only
need the top-level derivation. This is very wasteful: the closure can
contain thousands of store paths, and in some Hydra use cases, include
source paths that are very large (e.g. Git/Mercurial checkouts).
So now there is a new operation, StoreAPI::buildDerivation(), that
performs a build from an in-memory representation of a derivation
(BasicDerivation) rather than from a on-disk .drv file. The only files
that need to be in the Nix store are the sources of the derivation
(drv.inputSrcs), and the needed output paths of the dependencies (as
described by drv.inputDrvs). "nix-store --serve" exposes this
interface.
Note that this is a privileged operation, because you can construct a
derivation that builds any store path whatsoever. Fixing this will
require changing the hashing scheme (i.e., the output paths should be
computed from the other fields in BasicDerivation, allowing them to be
verified without access to other derivations). However, this would be
quite nice because it would allow .drv-free building (e.g. "nix-env
-i" wouldn't have to write any .drv files to disk).
Fixes #173.
2015-07-17 18:57:40 +03:00
|
|
|
struct Source;
|
|
|
|
struct Sink;
|
|
|
|
|
2022-03-18 17:35:45 +02:00
|
|
|
Source & readDerivation(Source & in, const StoreDirConfig & store, BasicDerivation & drv, std::string_view name);
|
|
|
|
void writeDerivation(Sink & out, const StoreDirConfig & store, const BasicDerivation & drv);
|
2012-11-26 16:39:10 +02:00
|
|
|
|
2023-03-26 01:12:44 +02:00
|
|
|
/**
|
|
|
|
* This creates an opaque and almost certainly unique string
|
|
|
|
* deterministically from the output name.
|
|
|
|
*
|
|
|
|
* It is used as a placeholder to allow derivations to refer to their
|
|
|
|
* own outputs without needing to use the hash of a derivation in
|
|
|
|
* itself, making the hash near-impossible to calculate.
|
|
|
|
*/
|
2023-08-25 16:53:12 +03:00
|
|
|
std::string hashPlaceholder(const OutputNameView outputName);
|
2016-08-17 16:12:54 +03:00
|
|
|
|
2022-03-30 17:31:01 +03:00
|
|
|
extern const Hash impureOutputHash;
|
|
|
|
|
2006-09-05 00:06:23 +03:00
|
|
|
}
|