## Keyboard shortcuts

Press `←` or `→` to navigate between chapters

Press `S` or `/` to search in the book

Press `?` to show this help

Press `Esc` to hide this help

# Glossary

- build system

  Generic term for software that facilitates the building of software by automating the invocation of compilers, linkers, and other tools.

  Nix can be used as a generic build system. It has no knowledge of any particular programming language or toolchain. These details are specified in derivation expressions.

- content address

  A content address is a secure way to reference immutable data. The reference is calculated directly from the content of the data being referenced, which means the reference is tamper proof --- variations of the data should always calculate to distinct content addresses.

  For how Nix uses content addresses, see:

  - Content-Addressing File System Objects
  - Content-Addressing Store Objects
  - content-addressing derivation

  Software Heritage's writing on Intrinsic and Extrinsic identifiers is also a good introduction to the value of content-addressing over other referencing schemes.

  Besides content addressing, the Nix store also uses input addressing.

- content-addressed storage

  The industry term for storage and retrieval systems using content addressing. A Nix store also has input addressing, and metadata.

- derivation

  A derivation can be thought of as a pure function that produces new store objects from existing store objects.

  Derivations are implemented as operating system processes that run in a sandbox. This sandbox by default only allows reading from store objects specified as inputs, and only allows writing to designated outputs to be captured as store objects.

  A derivation is typically specified as a derivation expression in the Nix language, and instantiated to a store derivation. There are multiple ways of obtaining store objects from store derivatons, collectively called realisation.

- store derivation

  A derivation represented as a store object.

  See Store Derivation for details.

- directed acyclic graph

  A directed acyclic graph (DAG) is graph whose edges are given a direction ("a to b" is not the same edge as "b to a"), and for which no possible path (created by joining together edges) forms a cycle.

  DAGs are very important to Nix. In particular, the non-self-references of store object form a cycle.

- derivation path

  A store path which uniquely identifies a store derivation.

  See Referencing Store Derivations for details.

  Not to be confused with [deriving path].

- derivation expression

  A description of a store derivation using the `derivation` primitive in the Nix language.

- instantiate, instantiation

  Translate a derivation expression into a store derivation.

  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
  - Building the corresponding store derivation
  - Delegating to a remote machine and retrieving the outputs

  See `nix-store --realise` for a detailed description of the algorithm.

  See also `nix-build` and `nix build` (experimental).

- content-addressing derivation

  A derivation which has the `__contentAddressed` attribute set to `true`.

- fixed-output derivation (FOD)

  A store derivation where a cryptographic hash of the output is determined in advance using the `outputHash` attribute, and where the `builder` executable has access to the network.

- store

  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.

- Nix instance

  1. An installation of Nix, which includes the presence of a store, and the Nix package manager which operates on that store. A local Nix installation and a remote builder are two examples of Nix instances.
  2. A running Nix process, such as the `nix` command.

- 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`

  See Store Path for details.

- file system object

  The Nix data model for representing simplified file system data.

  See File System Object for details.

- store object

  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.

- IFD

  Import From Derivation

- input-addressed store object

  A store object produced by building a non-content-addressed, non-fixed-output derivation.

  See input-addressing derivation outputs for details.

- content-addressed store object

  A store object which is content-addressed, i.e. whose store path is determined by its contents. This includes derivations, the outputs of content-addressing derivations, and the outputs of fixed-output derivations.

  See Content-Addressing Store Objects for details.

- 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 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.

- 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.

- impure derivation

  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.

- 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 syntactically valid use of the Nix language.

  > Example

  > The contents of a `.nix` file form a Nix expression.

  Nix expressions specify derivation expressions, which are instantiated into the Nix store as store derivations. These derivations can then be realised to produce outputs.

  > Example

  > Building and deploying software using Nix entails writing Nix expressions to describe packages and compositions thereof.

- reference

  An edge from one store object to another.

  See References for details.

  See References for details.

- reachable

  A store path `Q` is reachable from another store path `P` if `Q` is in the closure of the references relation.

  See References for details.

- 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`.

  See References for details.

- requisite

  A store object [reachable] by a path (chain of references) from a given store object. The closure is the set of requisites.

  See References for details.

- referrer

  A reversed edge from one store object to another.

- output

  A store object produced by a store derivation. See the `outputs` argument to the `derivation` function for details.

- output path

  The store path to the output of a store derivation.

- output closure
  The closure of an output path. It only contains what is [reachable] from the output.

- deriving path

  Deriving paths are a way to refer to store objects that might not yet be realised.

  See Deriving Path for details.

  Not to be confused with derivation path.

- deriver

  The store derivation that produced an output path.

  The deriver for an output path can be queried with the `--deriver` option to `nix-store --query`.

- 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.

- Nix Archive (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`.

  See Nix Archive for details.

- `∅`

  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.

- package

  A software package; files that belong together for a particular purpose, and metadata.

  Nix represents files as file system objects, and how they belong together is encoded as references between store objects that contain these file system objects.

  The Nix language allows denoting packages in terms of attribute sets containing:

  - attributes that refer to the files of a package, typically in the form of derivation outputs,
  - attributes with metadata, such as information about how the package is supposed to be used.

  The exact shape of these attribute sets is up to convention.

- string interpolation

  Expanding expressions enclosed in `${ }` within a string, path, or attribute name.

  See String interpolation for details.

- base directory

  The location from which relative paths are resolved.

  - For expressions in a file, the base directory is the directory containing that file. This is analogous to the directory of a base URL.
  - For expressions written in command line arguments with `--expr`, the base directory is the current working directory.

- 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.