![Valentin Gagarin](/assets/img/avatar_default.png)
after discussing this with multiple people, I'm convinced that "build task" is more precise: a derivation is not an action, but inert until it is built. also it's easier to pronounce. proposal: use "build task" for the generic concept "description of how to derive new files from the contents of existing files". then it will be easier to distinguish what we mean by "derivation" (a specific data structure and Nix language value type) and "store derivation" (a serialisation of a derivation into a file in the Nix store).
7 KiB
Glossary
-
[derivation]{#gloss-derivation}
A description of a build task. The result of a derivation is a store object. Derivations are typically specified in Nix expressions using thederivation
primitive. These are translated into low-level store derivations (implicitly bynix-env
andnix-build
, or explicitly bynix-instantiate
). -
[content-addressed derivation]{#gloss-content-addressed-derivation}
A derivation which has the__contentAddressed
attribute set totrue
. -
[fixed-output derivation]{#gloss-fixed-output-derivation}
A derivation which includes theoutputHash
attribute. -
[store]{#gloss-store}
The location in the file system where store objects live. Typically/nix/store
.From the perspective of the location where Nix is invoked, the Nix store can be referred to as a "local" or a "remote" one:
-
A local store exists on the filesystem of the machine where Nix is invoked. You can use other local stores by passing the
--store
flag to thenix
command. Local stores can be used for building derivations. -
A remote store exists anywhere other than the local filesystem. One example is the
/nix/store
directory on another machine, accessed viassh
or served by thenix-serve
Perl script.
-
-
[chroot store]{#gloss-chroot-store}
A local store whose canonical path is anything other than/nix/store
. -
[binary cache]{#gloss-binary-cache}
A binary cache is a Nix store which uses a different format: its metadata and signatures are kept in.narinfo
files rather than in a Nix database. This different format simplifies serving store objects over the network, but cannot host builds. Examples of binary caches include S3 buckets and the NixOS binary cache. -
[store path]{#gloss-store-path}
The location in the file system of a store object, i.e., an immediate child of the Nix store directory. -
[store object]{#gloss-store-object}
A file that is an immediate child of the Nix store directory. These can be regular files, but also entire directory trees. Store objects can be sources (objects copied from outside of the store), derivation outputs (objects produced by running a build task), or derivations (files describing a build task). -
[input-addressed store object]{#gloss-input-addressed-store-object}
A store object produced by building a non-content-addressed, non-fixed-output derivation. -
[output-addressed store object]{#gloss-output-addressed-store-object}
A store object whose store path hashes its content. This includes derivations, the outputs of content-addressed derivations, and the outputs of fixed-output derivations. -
[substitute]{#gloss-substitute}
A substitute is a command invocation stored in the Nix database that describes how to build a store object, bypassing the normal build mechanism (i.e., derivations). Typically, the substitute builds the store object by downloading a pre-built version of the store object from some server. -
[substituter]{#gloss-substituter}
A substituter is an additional store from which Nix will copy store objects it doesn't have. For details, see thesubstituters
option. -
[purity]{#gloss-purity}
The assumption that equal Nix derivations when run always produce the same output. This cannot be guaranteed in general (e.g., a builder can rely on external inputs such as the network or the system time) but the Nix model assumes it. -
[Nix expression]{#gloss-nix-expression}
A high-level description of software packages and compositions thereof. Deploying software using Nix entails writing Nix expressions for your packages. Nix expressions are translated to derivations that are stored in the Nix store. These derivations can then be built. -
[reference]{#gloss-reference}
A store pathP
is said to have a reference to a store pathQ
if the store object atP
contains the pathQ
somewhere. The references of a store path are the set of store paths to which it has a reference.A derivation can reference other derivations and sources (but not output paths), whereas an output path only references other output paths.
-
[reachable]{#gloss-reachable}
A store pathQ
is reachable from another store pathP
ifQ
is in the closure of the references relation. -
[closure]{#gloss-closure}
The closure of a store path is the set of store paths that are directly or indirectly “reachable” from that store path; that is, it’s the closure of the path under the references relation. For a package, the closure of its derivation is equivalent to the build-time dependencies, while the closure of its output path is equivalent to its runtime dependencies. For correct deployment it is necessary to deploy whole closures, since otherwise at runtime files could be missing. The commandnix-store -qR
prints out closures of store paths.As an example, if the store object at path
P
contains a reference to pathQ
, thenQ
is in the closure ofP
. Further, ifQ
referencesR
thenR
is also in the closure ofP
. -
[output path]{#gloss-output-path}
A store path produced by a derivation. -
[deriver]{#gloss-deriver}
The deriver of an output path is the store derivation that built it. -
[validity]{#gloss-validity}
A store path is considered valid if it exists in the file system, is listed in the Nix database as being valid, and if all paths in its closure are also valid. -
[user environment]{#gloss-user-env}
An automatically generated store object that consists of a set of symlinks to “active” applications, i.e., other store paths. These are generated automatically bynix-env
. See profiles. -
[profile]{#gloss-profile}
A symlink to the current user environment of a user, e.g.,/nix/var/nix/profiles/default
. -
[NAR]{#gloss-nar}
A Nix ARchive. This is a serialisation of a path in the Nix store. It can contain regular files, directories and symbolic links. NARs are generated and unpacked usingnix-store --dump
andnix-store --restore
. -
[
∅
]{#gloss-emtpy-set}
The empty set symbol. In the context of profile history, this denotes a package is not present in a particular version of the profile. -
[
ε
]{#gloss-epsilon}
The epsilon symbol. In the context of a package, this means the version is empty. More precisely, the derivation does not have a version attribute.