nix
Build and manage reproducible software environments
TLDR
Enable the nix command
Search for a package in nixpkgs via its name or description
Start a shell with the specified packages from nixpkgs available
Install some packages from nixpkgs permanently
Remove unused paths from Nix store to free up space
Start an interactive environment for evaluating Nix expressions
Display help for a specific subcommand
SYNOPSIS
nix <subcommand> [options] [arguments]
The nix command acts as a dispatcher for a suite of powerful subcommands, each designed for specific tasks. Common subcommands include build, shell, run, profile, store, flake, and repl.
PARAMETERS
--help
Show help for the specific subcommand or global help if no subcommand is specified.
--version
Show version information for nix.
--verbose, -v
Increase verbosity of logging output. Can be used multiple times for more detail.
--json
Output results in JSON format, useful for scripting and programmatic access.
--dry-run
Show what actions would be performed without actually executing them.
--experimental-features <features>
Enable specific experimental features, such as 'flakes' or 'nix-command'.
--cores <N>
Specify the number of CPU cores to use for builds. Defaults to the number of available cores.
--max-jobs <N>
Specify the maximum number of simultaneous build jobs.
DESCRIPTION
nix is a powerful and unique package manager and build system that emphasizes reproducibility, reliability, and declarative configuration. Unlike traditional package managers, nix builds and manages software in isolated environments within the Nix store (typically /nix/store
), preventing dependency conflicts and ensuring that builds are perfectly reproducible regardless of the system's state.
Its core philosophy is based on purely functional programming principles: all inputs to a build are precisely defined, and the output is cryptographically hashed, meaning identical inputs always yield identical outputs. This enables features like atomic upgrades, rollbacks, and the ability to run multiple versions of the same software side-by-side without interference.
Beyond mere package management, nix also serves as a robust build system and is the foundation for NixOS, a declarative operating system. It's widely used for setting up reproducible development environments, continuous integration/delivery (CI/CD) pipelines, and robust system deployments.
CAVEATS
Steep Learning Curve: Nix introduces fundamentally different concepts (purely functional, declarative, immutable store) compared to traditional Linux package management, leading to a significant initial learning investment.
Disk Space Usage: The immutable nature of the Nix store means that new versions of packages and all their dependencies are stored separately, which can lead to higher disk space consumption over time if garbage collection is not regularly performed.
Integration with FHS: Integrating Nix-managed software with systems or applications expecting the traditional Filesystem Hierarchy Standard (FHS) layouts (e.g., binaries in /usr/bin
, libraries in /usr/lib
) can sometimes be challenging, although nix provides mechanisms for this.
THE NIX STORE
The Nix store, typically located at /nix/store
, is the central immutable repository where all Nix-managed software, libraries, and configurations are stored. Each package or component in the store has a unique cryptographic hash in its path (e.g., /nix/store/<hash>-<name>
), ensuring that different versions or builds of the same software can coexist without conflict and that outputs are always identical for identical inputs. This isolation is key to Nix's reproducibility and reliability.
NIX LANGUAGE AND EXPRESSIONS
Nix uses its own declarative, lazily evaluated, functional programming language (the Nix language) to define packages, system configurations, and build instructions. These definitions are called Nix expressions. This language allows users to precisely specify dependencies, build steps, and environment setups in a highly composable and reusable manner, making complex configurations manageable and reproducible across different systems.
NIX FLAKES
Nix Flakes are a modern, experimental feature (now widely adopted) that simplify managing and sharing Nix projects. A flake is a directory containing a flake.nix
file that declares its inputs (dependencies) and outputs (packages, applications, dev shells, etc.). Flakes provide a standardized way to define reproducible development environments and deployable artifacts, improving usability and portability of Nix projects.
HISTORY
The Nix package manager was conceived by Eelco Dolstra as part of his doctoral research at Utrecht University in the early 2000s, with the first public release around 2003. Its development was driven by the desire to overcome the reproducibility and dependency problems inherent in traditional package management systems. The ideas laid out in Nix later formed the foundation for NixOS, a Linux distribution built entirely on Nix's declarative and reproducible principles. Over the years, Nix has evolved significantly, gaining traction among developers and system administrators seeking robust, reliable, and reproducible software environments, particularly with the advent of 'Nix Flakes' in recent years streamlining its usage.