Nix (package manager): Difference between revisions
m add subsection linking how to garbage collect the nix store |
m Remove dead link |
||
| (9 intermediate revisions by 3 users not shown) | |||
| Line 2: | Line 2: | ||
<translate> | <translate> | ||
<!--T:1--> | <!--T:1--> | ||
{{Navbox Nix}} | |||
{{Disambiguation|message=This article is about the Nix package manager. Not to be confused with the [[Nix ecosystem]], the [[Nix (language)|Nix language]] or the [[Nix (command)|Nix command]].}} | |||
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<ref>Values cannot change during computation. Functions always produce the same output if their input does not change. </ref>taking dependencies as arguments and producing a ''[[Derivations|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 (aka the [[#Nix store|nix 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<ref>Values cannot change during computation. Functions always produce the same output if their input does not change. </ref>taking dependencies as arguments and producing a ''[[Derivations|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 (aka the [[#Nix store|nix 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]. | ||
| Line 8: | Line 10: | ||
<!--T:3--> | <!--T:3--> | ||
=== Installation === | === Installation === | ||
On NixOS, Nix is automatically installed. | On [[NixOS]], Nix is automatically installed. | ||
<!--T:4--> | <!--T:4--> | ||
| Line 16: | Line 18: | ||
<!--T:6--> | <!--T:6--> | ||
The [[Nix command|Nix commands]] are documented in the [https://nixos.org/manual/nix/stable/command-ref/command-ref Nix reference manual]: main commands, utilities and experimental commands. Prior to version 2.0 (released in February 2018) there have been different commands. | The [[Nix (command line utilities)|Nix commands]] are documented in the [https://nixos.org/manual/nix/stable/command-ref/command-ref Nix reference manual]: main commands, utilities and experimental commands. Prior to version 2.0 (released in February 2018) there have been different commands. | ||
<!--T:7--> | <!--T:7--> | ||
| Line 32: | Line 34: | ||
=== Nix store === <!--T:11--> | === Nix store === <!--T:11--> | ||
<!--T: | <!--T:27--> | ||
{{Split|reason=The nix store is conceptually separate enough that it warrants a separate article.}} | |||
<!--T:28--> | |||
Packages built by Nix are placed in the read-only ''Nix store'', normally found in <code>/nix/store</code>. Each package is given a unique address specified by a cryptographic hash followed by the package name and version, for example <code>/nix/store/nawl092prjblbhvv16kxxbk6j9gkgcqm-git-2.14.1</code>. 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, symlinks to these packages are added, removed or changed in ''profiles''. | Packages built by Nix are placed in the read-only ''Nix store'', normally found in <code>/nix/store</code>. Each package is given a unique address specified by a cryptographic hash followed by the package name and version, for example <code>/nix/store/nawl092prjblbhvv16kxxbk6j9gkgcqm-git-2.14.1</code>. 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, symlinks to these packages are added, removed or changed in ''profiles''. | ||
==== Cleaning the Nix store ==== | ==== Cleaning the Nix store ==== <!--T:29--> | ||
<!--T:30--> | |||
For information relating to cleaning the Nix store, refer to {{NixOS Manual|name=NixOS Manual: Chapter - Cleaning the Nix Store|anchor=#sec-nix-gc}}. | For information relating to cleaning the Nix store, refer to {{NixOS Manual|name=NixOS Manual: Chapter - Cleaning the Nix Store|anchor=#sec-nix-gc}}. | ||
==== Nix store corruption ==== <!--T:31--> | |||
<!--T:32--> | |||
For information relating to fixing a corrupted Nix store, refer to {{NixOS Manual|name=NixOS Manual: Chapter - Nix Store Corruption|anchor=#sec-nix-store-corruption}}. | |||
==== Valid Nix store names ==== <!--T:33--> | |||
<!--T:34--> | |||
{{main|Valid Nix store path names}} | |||
=== Profiles === <!--T:13--> | === Profiles === <!--T:13--> | ||
| Line 47: | Line 63: | ||
<!--T:16--> | <!--T:16--> | ||
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 <code>fetch*</code> 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) | 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 <code>fetch*</code> 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). | ||
<!--T:17--> | <!--T:17--> | ||