Glossary
-
A description of a build task. The result of a derivation is a store object. Derivations declared in Nix expressions are specified using the
derivation
primitive. These are translated into low-level store derivations (implicitly bynix-build
, or explicitly bynix-instantiate
). -
A derivation represented as a
.drv
file in the store. It has a store path, like any store object. It is the instantiated form of a derivation.Example:
/nix/store/g946hcz4c8mdvq2g8vxx42z51qb71rvp-git-2.38.1.drv
See
nix derivation show
(experimental) for displaying the contents of store derivations. -
instantiate, instantiation
Save an evaluated derivation as a store derivation in the Nix store.
See
nix-instantiate
, which produces a store derivation from a Nix expression that evaluates to a derivation. -
realise, realisation
Ensure a store path is valid.
This can be achieved by:
- Fetching a pre-built store object from a substituter
- Running the
builder
executable as specified in the corresponding derivation - Delegating to a remote machine and retrieving the outputs
See
nix-store --realise
for a detailed description of the algorithm. -
A derivation which has the
__contentAddressed
attribute set totrue
. -
A derivation which includes the
outputHash
attribute. -
A collection of store objects, with operations to manipulate that collection. See Nix Store for details.
There are many types of stores, see Store Types for details.
-
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. -
The location of a store object in the file system, i.e., an immediate child of the Nix store directory.
Example
/nix/store/a040m110amc4h71lds2jmr8qrkj2jhxd-git-2.38.1
See Store Path for details.
-
The Nix data model for representing simplified file system data.
See File System Object for details.
-
Part of the contents of a store.
A store object consists of a file system object, references to other store objects, and other metadata. It can be referred to by a store path.
See Store Object for details.
-
A store object produced by building a non-content-addressed, non-fixed-output derivation.
-
content-addressed store object
A store object whose store path is determined by its contents. This includes derivations, the outputs of content-addressed derivations, and the outputs of fixed-output derivations.
-
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.
-
An additional store from which Nix can obtain store objects instead of building them. Often the substituter is a binary cache, but any store can serve as substituter.
See the
substituters
configuration option for details. -
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.
-
An experimental feature that allows derivations to be explicitly marked as impure, so that they are always rebuilt, and their outputs not reused by subsequent calls to realise them.
-
An SQlite database to track references between store objects. This is an implementation detail of the local store.
Default location:
/nix/var/nix/db
. -
-
Commonly, a high-level description of software packages and compositions thereof. Deploying software using Nix entails writing Nix expressions for your packages. Nix expressions specify derivations, which are instantiated into the Nix store as store derivations. These derivations can then be realised to produce outputs.
-
A syntactically valid use of the Nix language. For example, the contents of a
.nix
file form an expression.
-
-
A store object
O
is said to have a reference to a store objectP
if a store path toP
appears in the contents ofO
.Store objects can refer to both other store objects and themselves. References from a store object to itself are called self-references. References other than a self-reference must not form a cycle.
-
A store path
Q
is reachable from another store pathP
ifQ
is in the closure of the references relation. -
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 command
nix-store --query --requisites
prints out closures of store paths.As an example, if the store object at path
P
contains a reference to a store object at pathQ
, thenQ
is in the closure ofP
. Further, ifQ
referencesR
thenR
is also in the closure ofP
. -
A store object produced by a derivation. See the
outputs
argument to thederivation
function for details. -
The store path to the output of a derivation.
-
The store derivation that produced an output path.
The deriver for an output path can be queried with the
--deriver
option tonix-store --query
. -
A store path is valid if all store objects in its closure can be read from the store.
For a local store, this means:
- The store path leads to an existing store object in that store.
- The store path is listed in the Nix database as being valid.
- All paths in the store path's closure are valid.
-
An automatically generated store object that consists of a set of symlinks to “active” applications, i.e., other store paths. These are generated automatically by
nix-env
. See profiles. -
A symlink to the current user environment of a user, e.g.,
/nix/var/nix/profiles/default
. -
Something that can be realised in the Nix store.
See installables for
nix
commands (experimental) for details. -
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 using
nix-store --dump
andnix-store --restore
. -
The empty set symbol. In the context of profile history, this denotes a package is not present in a particular version of the profile.
-
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.
-
-
A software package; a collection of files and other data.
-
-
An attribute set containing the attribute
type = "derivation";
(derivation for historical reasons), as well as other attributes, such as- attributes that refer to the files of a [package], typically in the form of derivation outputs,
- attributes that declare something about how the package is supposed to be installed or used,
- other metadata or arbitrary attributes.
-
Expanding expressions enclosed in
${ }
within a string, path, or attribute name.See String interpolation for details.
-
Not yet stabilized functionality guarded by named experimental feature flags. These flags are enabled or disabled with the
experimental-features
setting.See the contribution guide on the purpose and lifecycle of experimental feaures.