Decoding the Lexicon of Purity

Nix has its own vocabulary, the terminology can be confusing. Many words have highly precise mathematical or functional meanings that differ from standard Linux jargon.

Declarative

A programming paradigm where you describe what the system should look like (the desired end-state), rather than how to achieve it (a sequence of commands). NixOS is fully declarative: you write down the configuration, and Nix computes how to configure the services, write files, and install packages to match.

Functional

A programming paradigm where programs are constructed by applying and composing functions. Nix is a purely functional language: functions are first-class, variables are immutable (you cannot reassign a value once defined), and functions have no side effects (calling a function with the same inputs always returns the same output).

Idempotency

The property of certain operations where they can be applied multiple times without changing the result beyond the initial application.

Derivation (.drv)

A derivation is a build recipe. It is a plain-text file (ending in .drv) that describes how to build a package. It includes all dependencies, build steps, environment variables, and the target store path.

Realisation (Realise)

To realise a derivation means to actually run the build process described in the .drv file.

The Store

The readonly directory /nix/store is the heart of Nix. It contains all packages, configurations, scripts, and build inputs. Every item is stored under a unique path that contains a cryptographic hash of its inputs.

FHS (Filesystem Hierarchy Standard)

The traditional directory layout of Unix-like operating systems (defining paths like /bin, /usr/lib, /var/log). Nix explicitly rejects the standard FHS layout to prevent dependency collision and guarantee reproducibility.

Hermetic Build

A build that is entirely self-contained and isolated from the host operating system. A hermetic build execution ensures that only declared tools, dependencies, and environment variables are accessible, leaving no room for “ambient” system state to leak into the compiler.

Path

A built-in data type in the Nix language representing a file system path, written without quotes (e.g. ./default.nix or /etc/resolv.conf).

Attribute Set (AttrSet)

A key-value pair structure in the Nix language, written with curly braces { name = "value"; }. It is the primary data structure used for passing configurations and defining packages in Nix.

Expression

A piece of code written in the Nix language that can be evaluated to a value. Because Nix is a functional language, almost everything is an expression - functions, conditionals, attribute sets, and values.

Channel

A mechanism for distributing Nix packages. A channel is a rolling release branch of Nixpkgs that has successfully passed all of Nix’s automated integration tests.

Nixpkgs

The mammoth Git repository containing the official collection of Nix packages and NixOS modules. It is one of the largest and most active software repositories on GitHub.

NixOS

A Linux distribution built on top of the Nix package manager. It uses a declarative configuration file (usually /etc/nixos/configuration.nix) to manage the entire operating system, including the kernel, services, packages, and user accounts.

Overlay

A mechanism to modify or extend the nixpkgs package set. Overlays allow you to override specific package attributes, add new packages, or apply patches to existing ones without having to fork the entire repository.

Home Manager

A community-driven tool that uses the Nix package manager to manage user-specific configuration (“dotfiles”) and user-level packages in a declarative manner.

Substituter

A substituter is a remote binary cache. When Nix needs to realise a derivation, it first checks if a pre-compiled version of the output path exists on any registered substituter (like cache.nixos.org). If it exists, Nix downloads the pre-built binary instead of compiling it locally.

Purity

Purity is the concept that a build function should only depend on its declared inputs and must not produce side effects. In Nix, builds run in highly isolated sandboxes with no network access (unless explicitly permitted for fetching sources) and minimal environment variables.

Closure

The closure of a store path is the path itself plus all of its direct and indirect dependencies.

Flake

An experimental but widely adopted Nix feature that provides a standardized structure for Nix projects. A flake specifies explicit inputs (like other repositories or channels) and outputs (like packages, modules, or templates) in a flake.nix file.

flake.lock

The JSON lockfile automatically generated and updated by Nix flakes. It pins every single input to an exact cryptographic commit hash, version, or URI.

Impermanence

An advanced NixOS architecture pattern where the root filesystem (/) is mounted as a temporary RAM disk (tmpfs) or wiped on every boot. Only explicitly defined directories and files (like your home directory, system databases, or SSH keys) are persisted to a separate, persistent partition (typically /persist).

passthru

An attribute in Nix derivations used to attach arbitrary information, utilities, or scripts to a package without affecting its build hash.

Fixed-Output Derivation (FOD)

A derivation where the cryptographic hash of the output is declared in advance (using hash or sha256). Because the expected hash is known beforehand, Nix relaxes its strict sandboxing and allows the build sandbox network access to fetch sources (e.g., source tarballs or packages from a package registry like Cargo, npm, or Go modules).

Cryptographic Hash

A unique digital fingerprint used to verify the integrity and identity of files, archives, and derivations in Nix.

NAR (Nix Archive)

A simple serialization format used by Nix to represent a directory tree or a single file as a single contiguous byte stream. Unlike standard archiving formats (like .tar or .zip), the NAR format is strictly deterministic: archiving the same files with the same permissions and structure will always produce the exact same byte-for-byte output.

NAR Hash (narHash)

The cryptographic hash of a file or directory tree computed after converting it into the NAR serialization format. This is the primary hash Nix uses to represent the contents of any path in the /nix/store.

File Hash (Flat Hash)

The direct cryptographic hash of a single file’s raw content (equivalent to running sha256sum <file>), without any surrounding NAR serialization or metadata.

Stdenv (Standard Environment)

The default build environment in Nixpkgs. It provides a standard set of compilers (GCC/Clang), core POSIX/GNU utilities (like bash, coreutils, make, sed, grep), and the standard builder execution phases (unpack, patch, configure, build, check, install).

REPL (Read-Eval-Print Loop)

An interactive shell for evaluating Nix expressions in real-time. Run nix repl to open it. It is incredibly useful for inspecting attribute sets, testing functions, or exploring package variables in a running environment.

Development Shell (devShell)

A reproducible terminal environment designed for development. Built via nix-shell or nix develop (for flakes), it sets up all necessary packages, compiler flags, and environment variables on the fly without installing anything globally to your system.

• In other words: A temporary workspace containerized at the environment variable level.

Garbage Collection (GC)

Since every build or package variant gets its own immutable path in the Nix store, disk space can fill up fast. The garbage collector (nix-collect-garbage) identifies paths in /nix/store that are no longer referenced by any active “GC root” (like system profiles, active user profiles, or development shells) and safely deletes them.

GC Root (Garbage Collector Root)

An entry point or symlink that tells the Garbage Collector not to delete a particular store path. Active profiles, NixOS configurations, development shells, and pinned project builds are registered as GC roots.

Profile

A set of symlinks that points to a specific generation of packages installed for a user or the system. Profiles are stored in /nix/var/nix/profiles.

Generation

A specific version of a profile. Each time you run a command that modifies a profile (e.g., updating user packages, changing your NixOS configuration), Nix creates a new generation. Old generations are kept around so that you can instantly roll back if needed.

String Context

Under the hood, Nix strings aren’t just arrays of characters. If a string is created by referencing a path or package (e.g., "${pkgs.hello}"), it carries a hidden cargo called string context. This context tracks which store paths are referenced by the string, ensuring that whenever that string is used in a derivation, Nix knows to include those paths in the build dependencies.

override vs overrideAttrs

Two of the most frequently used helper functions in Nixpkgs for customizing packages.

• override: Modifies the inputs (arguments) passed to the package function itself. For example, replacing a package’s default dependency with a customized version.
• overrideAttrs: Modifies the attributes of the underlying derivation itself (like pname, version, src, patches, buildInputs, postInstall, etc.) which are passed to stdenv.mkDerivation.

meta attribute

An optional attribute inside a package derivation containing metadata. It does not affect the package build hash.

callPackage

The standard dependency injection pattern used in Nixpkgs. Instead of manually specifying all package dependencies, pkgs.callPackage ./file.nix { } automatically parses the arguments of the given file and fills in the matching packages from Nixpkgs.

lib (Nixpkgs Utility Library)

A collection of utility functions bundled inside Nixpkgs. It contains hundreds of helpers for working with Nix data types—such as lists, strings, attribute sets, and path systems—along with tools for defining NixOS option structures.

• Usage: Accessible globally via the lib parameter in module or package functions.

NixOS Module

A structured Nix file that integrates into the NixOS option tree. A module is a function that usually takes { config, lib, pkgs, ... } and returns an attribute set with three main keys:

• imports: A list of other modules to pull in.
• options: Defines new configurable options (using lib.mkOption or lib.mkEnableOption).
• config: Defines the actual settings and values applied to the system based on configured options.

lib.mkIf, lib.mkMerge, lib.mkForce

Helper functions in the Nixpkgs lib library used within NixOS and Home Manager modules to manage option declaration and precedence:

• mkIf: Conditionally applies configurations (e.g., config = lib.mkIf config.services.nginx.enable { ... };).
• mkMerge: Merges multiple configuration blocks together.
• mkForce: Forces an option to a specific value, overriding standard module priorities and values defined elsewhere.

Pure vs Impure Evaluation

• Pure Evaluation: The evaluation mode enforced by Flakes. The Nix evaluator has no access to environment variables, system directories, or network locations (unless they are tracked inputs in flake.lock). This guarantees absolute determinism.
• Impure Evaluation: Allows the evaluator to read host system files, environment variables, or retrieve untracked content. When using flakes, you must pass the --impure flag explicitly to allow this.

Nix Daemon (nix-daemon)

A background service that runs on multi-user Nix installs (including NixOS). The daemon runs as root and handles all store writes, builds, and operations, while unprivileged users communicate with it over a local socket.

Evaluation Time (Eval-time)

The phase where the Nix interpreter reads your Nix files, parses your expressions, and evaluates them to determine exactly what needs to be built.

Build Time (Instantiation / Realisation)

The phase where the derivations calculated during evaluation are built. Nix executes the compiler, unpacks the source files, and runs the build steps within a highly isolated sandbox.

Runtime (Execution time)

The phase when the compiled and installed application actually executes on the user’s system.

buildInputs vs nativeBuildInputs

One of the most confusing distinctions for newcomers, defining where a dependency is expected to execute:

• nativeBuildInputs: Build-time tools that must execute on the architecture of the host system doing the compilation (e.g., compilers like GCC, or code-generators like CMake, pkg-config).
• buildInputs: Software dependencies or libraries that will run on or link against the target architecture where the final package will execute (e.g., openssl, glibc, or dependency libraries).

Multiple Outputs

A derivation design pattern that splits a built package into separate sub-store-paths (such as out, bin, lib, dev, man, doc).