nix-super/doc/manual/glossary.xml

<appendix><title>Glossary</title>

<glosslist>


<glossentry id="gloss-derivation"><glossterm>derivation</glossterm>

  <glossdef><para>A description of a build action.  The result of a
  derivation is a store object.  Derivations are typically specified
  in Nix expressions using the <link
  linkend="ssec-derivation"><function>derivation</function>
  primitive</link>.  These are translated into low-level
  <emphasis>store derivations</emphasis> (implicitly by
  <command>nix-env</command> and <command>nix-build</command>, or
  explicitly by <command>nix-instantiate</command>).</para></glossdef>

</glossentry>


<glossentry><glossterm>store</glossterm>

  <glossdef><para>The location in the file system where store objects
  live.  Typically <filename>/nix/store</filename>.</para></glossdef>

</glossentry>


<glossentry><glossterm>store path</glossterm>

  <glossdef><para>The location in the file system of a store object,
  i.e., an immediate child of the Nix store
  directory.</para></glossdef>

</glossentry>


<glossentry><glossterm>store object</glossterm>

  <glossdef><para>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
  action), or derivations (files describing a build
  action).</para></glossdef>

</glossentry>


<glossentry id="gloss-substitute"><glossterm>substitute</glossterm>

  <glossdef><para>A substitute is a command invocation stored in the
  Nix database that describes how to build a store object, bypassing
  normal the 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.</para></glossdef>

</glossentry>


<glossentry><glossterm>purity</glossterm>

  <glossdef><para>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.</para></glossdef>

</glossentry>


<glossentry><glossterm>Nix expression</glossterm>

  <glossdef><para>A high-level description of software components and
  compositions thereof.  Deploying software using Nix entails writing
  Nix expressions for your components.  Nix expressions are translated
  to derivations that are stored in the Nix store.  These derivations
  can then be built.</para></glossdef>

</glossentry>


<glossentry id="gloss-reference"><glossterm>reference</glossterm>

  <glossdef><para>A store path <varname>P</varname> is said to have a
  reference to a store path <varname>Q</varname> if the store object
  at <varname>P</varname> contains the path <varname>Q</varname>
  somewhere.  This implies than an execution involving
  <varname>P</varname> potentially needs <varname>Q</varname> to be
  present.  The <emphasis>references</emphasis> of a store path are
  the set of store paths to which it has a reference.</para></glossdef>

</glossentry>


<glossentry id="gloss-closure"><glossterm>closure</glossterm>

  <glossdef><para>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 <link
  linkend="gloss-reference">references</link> relation.  For instance,
  if the store object at path <varname>P</varname> contains a
  reference to path <varname>Q</varname>, then <varname>Q</varname> is
  in the closure of <varname>P</varname>.  For correct deployment it
  is necessary to deploy whole closures, since otherwise at runtime
  files could be missing.  The command <command>nix-store
  -qR</command> prints out closures of store paths.</para></glossdef>

</glossentry>


<glossentry id="gloss-output-path"><glossterm>output path</glossterm>

  <glossdef><para>A store path produced by a derivation.</para></glossdef>

</glossentry>


<glossentry id="gloss-deriver"><glossterm>deriver</glossterm>

  <glossdef><para>The deriver of an <link
  linkend="gloss-output-path">output path</link> is the store
  derivation that built it.</para></glossdef>

</glossentry>


<glossentry id="gloss-validity"><glossterm>validity</glossterm>

  <glossdef><para>A store path is considered
  <emphasis>valid</emphasis> 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.</para></glossdef>

</glossentry>


<glossentry id="gloss-user-env"><glossterm>user environment</glossterm>

  <glossdef><para>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 <link
  linkend="sec-nix-env"><command>nix-env</command></link>.  See <xref
  linkend="sec-profiles" />.</para>

  </glossdef>
  
</glossentry>


<glossentry id="gloss-profile"><glossterm>profile</glossterm>

  <glossdef><para>A symlink to the current <link
  linkend="gloss-user-env">user environment</link> of a user, e.g.,
  <filename>/nix/var/nix/profiles/default</filename>.</para></glossdef>

</glossentry>



</glosslist>


</appendix>