Glossary
derivation
A description of a build task. The result of a derivation is a
store object. Derivations are typically specified in Nix expressions
using the derivation primitive. These are
translated into low-level store derivations (implicitly by
nix-env and nix-build, or explicitly by nix-instantiate).
store derivation
A derivation represented as a .drv file in the store.
It has a store path, like any store object.
Example: /nix/store/g946hcz4c8mdvq2g8vxx42z51qb71rvp-git-2.38.1.drv
See nix derivation show (experimental) for displaying the contents of store derivations.
instantiate, instantiation
Translate a derivation into a store derivation.
See nix-instantiate.
realise, realisation
Ensure a store path is valid.
This means either running the builder executable as specified in the corresponding derivation, or fetching a pre-built store object from a substituter, or delegating to a remote builder and retrieving the outputs.
See nix-build and nix-store --realise.
See nix build (experimental).
content-addressed derivation
A derivation which has the
__contentAddressed
attribute set to true.
fixed-output derivation
A derivation which includes the
outputHash attribute.
store
The location in the file system where store objects live. Typically
/nix/store.
From the perspective of the location where Lix is invoked, the Nix store can be referred to as a "local" or a "remote" one:
-
A local store exists on the filesystem of {#gloss-local-store} the machine where Lix is invoked. You can use other local stores by passing the
--storeflag to thenixcommand. Local stores can be used for building derivations. -
A remote store exists anywhere other than the local filesystem. One example is the
/nix/storedirectory on another machine, accessed viasshor served by thenix-servePerl script.
chroot store
A local store whose canonical path is anything other than /nix/store.
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
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
file system object
The Nix data model for representing simplified file system data.
See File System Object for details.
store object
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.
input-addressed store object
A store object produced by building a non-content-addressed, non-fixed-output derivation.
output-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.
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
An additional store from which Lix can obtain store objects instead of building them. {#gloss-store} Often the substituter is a binary cache, but any store can serve as substituter.
See the substituters configuration option for details.
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 database
An SQlite database to track references between store objects. This is an implementation detail of the local store.
Default location: /nix/var/nix/db.
Nix expression
A high-level description of software packages and compositions thereof. Deploying software using Lix 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
A store object O is said to have a reference to a store object P if a store path to P appears in the contents of O.
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.
reachable
A store path Q is reachable from another store path P if Q
is in the closure of the references relation.
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 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 path Q, then Q is in the closure of P. Further, if Q
references R then R is also in the closure of P.
output
A store object produced by a derivation.
output path
The store path to the output of a derivation.
deriver
The store derivation that produced an output path.
validity
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.
user environment
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.
profile
A symlink to the current user environment of a user, e.g.,
/nix/var/nix/profiles/default.
installable
Something that can be realised in the Nix store.
See installables for nix commands (experimental) for details.
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 using nix-store --dump
and nix-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.
string interpolation
Expanding expressions enclosed in $ { } within a string, path, or attribute name.
See String interpolation for details.
experimental feature
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.