Nix (package manager): Difference between revisions
m Replaced dead link in the "Installation" section and removed "NixOS ships with Nix pre-installed." because its extremely obvious. |
m typo Tags: Mobile edit Mobile web edit |
||
| Line 1: | Line 1: | ||
Nix is a package manager and build system that parses reproducible build instructions specified in the [[Nix Expression Language]], a pure functional language with lazy evaluation. Nix expressions are pure functions taking dependencies as arguments and producing ''derivation'' specifying a reproducible build environment for the package. Nix stores the results of the build in unique addresses specified by a hash of the complete dependency tree, creating an immutable package store that allows for atomic upgrades, rollbacks and concurrent installation of different versions of a package, essentially eliminating [https://en.wikipedia.org/wiki/Dependency_hell dependency hell]. | Nix is a package manager and build system that parses reproducible build instructions specified in the [[Nix Expression Language]], a pure functional language with lazy evaluation. Nix expressions are pure functions taking dependencies as arguments and producing a ''derivation'' specifying a reproducible build environment for the package. Nix stores the results of the build in unique addresses specified by a hash of the complete dependency tree, creating an immutable package store that allows for atomic upgrades, rollbacks and concurrent installation of different versions of a package, essentially eliminating [https://en.wikipedia.org/wiki/Dependency_hell dependency hell]. | ||
== Usage == | == Usage == | ||
Revision as of 04:01, 11 April 2024
Nix is a package manager and build system that parses reproducible build instructions specified in the Nix Expression Language, a pure functional language with lazy evaluation. Nix expressions are pure functions taking dependencies as arguments and producing a derivation specifying a reproducible build environment for the package. Nix stores the results of the build in unique addresses specified by a hash of the complete dependency tree, creating an immutable package store that allows for atomic upgrades, rollbacks and concurrent installation of different versions of a package, essentially eliminating dependency hell.
Usage
Installation
The installation section of the Nix manual describes the installation of standalone Nix from binary or source for Linux and Mac systems.
Nix commands
Since Nix 2.0 there is a new style of commands. Those are documented in the Nix reference manual. See Nix command for additional information.
Configuration
On NixOS, Nix is configured through the nix option.
Standalone Nix is configured through nix.conf (usually found in /etc/nix/), which defines a number of settings relating to evaluation, builds, garbage collection, sandboxing, and user permissions. Details on the available options are found in the Nix reference manual.
Outside of NixOS, Home Manager is the preferred way to manage declarative environments for a single user. For system-wide configuration on Linux, use System Manager. For system-wide configuration on macOS, nix-darwin is the preferred solution.
Internals
Nix store
Packages built by Nix are placed in the read-only Nix store, normally found in /nix/store. Each package is given a unique address specified by a cryptographic hash followed by the package name and version, for example /nix/store/nawl092prjblbhvv16kxxbk6j9gkgcqm-git-2.14.1. These prefixes hash all the inputs to the build process, including the source files, the full dependency tree, compiler flags, etc. This allows Nix to simultaneously install different versions of the same package, and even different builds of the same version, for example variants built with different compilers. When adding, removing or updating a package, nothing is removed from the store; instead, it symlinks to these packages are added, removed or changed in profiles.
Profiles
In order to construct a coherent user or system environment, Nix symlinks entries of the Nix store into profiles. These are the front-end by which Nix allows rollbacks: since the store is immutable and previous versions of profiles are kept, reverting to an earlier state is simply a matter of change the symlink to a previous profile. To be more precise, Nix symlinks binaries into entries of the Nix store representing the user environments. These user environments are then symlinked into labeled profiles stored in /nix/var/nix/profiles, which are in turn symlinked to the user's ~/.nix-profile.
Sandboxing
When sandbox builds are enabled, Nix will setup an isolated environment for each build process. It is used to remove further hidden dependencies set by the build environment to improve reproducibility. This includes access to the network during the build outside of fetch* functions and files outside the Nix store. Depending on the operating system access to other resources are blocked as well (ex. inter process communication is isolated on Linux); see nix.conf section in the Nix manual for details.
Sandboxing is enabled by default on Linux, and disabled by default on macOS.
In pull requests for Nixpkgs people are asked to test builds with sandboxing enabled (see Tested using sandboxing in the pull request template) because in official Hydra builds sandboxing is also used.
To configure Nix for sandboxing, set sandbox = true in /etc/nix/nix.conf; to configure NixOS for sandboxing set nix.useSandbox = true; in configuration.nix. The nix.useSandbox option is true by default since NixOS 17.09.
Alternative Interpreters
There is an ongoing effort to reimplement Nix, from the ground up, in Rust.
Earlier attempts can be found on riir-nix