Jump to content

Nix (package manager): Difference between revisions

From NixOS Wiki
← Older edit
Visual
imported>Ixxie
DoggoBit (talk | contribs)
trusted
1,046 edits
m Add navbox
 
(59 intermediate revisions by 29 users not shown)
Line 1: Line 1:
{{Expansion|This article is incomplete.}}
<languages/>
<translate>
<!--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 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 dependence 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 == <!--T:2-->


== Usage ==
<!--T:3-->
=== Installation ===
On [[NixOS]], Nix is automatically installed.
 
<!--T:4-->
On other Linux distributions or on macOS, you can install Nix following the [https://nixos.org/manual/nix/stable/installation/installation installation section of the Nix manual].
 
=== Nix commands === <!--T:5-->


=== Installation ===
<!--T:6-->
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.


The [https://nixos.org/nix/manual/#chap-installation installation section of the Nix manual] describes how to install Nix from binary or source on Linux and Mac systems for a user with root privileges; it is easiest to install Nix for a single user, but steps are also included for setting up a multiuser installation. For an extensive guide on various methods for installing Nix - including how to install Nix without root privileges - see the [[Nix Installation Guide]].
<!--T:7-->
=== Configuration ===
On NixOS, Nix can be configured using the [https://search.nixos.org/options?query=nix. <code>nix</code> option].  


=== Declarative Configuration ===
<!--T:8-->
Standalone Nix is configured through <code>nix.conf</code> (usually found in <code>/etc/nix/</code>). Details on the available options are [https://nixos.org/manual/nix/stable/command-ref/conf-file found in the Nix reference manual].


Support for declarative configuration in Nix is limited, and the solutions are somewhat fragmented. The only only configuration file officially associated with Nix is <code>nix.conf</code> (usually found in <code>/etc/nix/</code>), which defines a number of settings relating to how Nix, including build, garbage collection, sandboxing, and user permissions. Details on the available options are found in the [https://nixos.org/nix/manual/#sec-conf-file|nix.conf section of the manual]. Since most scenarios involve using [[Nixpkgs]], configuration of <code>~/.config/nixpkgs/config.nix</code> is often also helpful; here package overrides can be specified. Work on Nix user profiles is well underway, see [https://github.com/NixOS/nixpkgs/pull/9250|PR 9250].
<!--T:9-->
You can also configure Nix using [[Home Manager]], which manages declarative environments for a single user. For system-wide configuration, you can use [https://github.com/numtide/system-manager System Manager] on Linux and [https://github.com/LnL7/nix-darwin nix-darwin] on macOS.


=== Imperative Operations ===
== Internals == <!--T:10-->


=== Nix store === <!--T:11-->


====  User Environments ====
{{Split|reason=The nix store is conceptually separate enough that it warrants a separate article.}}


Nix offers an imperative package management command line tool - <code>nix-env</code> - which can be used to install packages at the user level. Packages installed using <code>nix-env</code> are only available to the given user, and do not change system state.
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''.


{|  class="wikitable"
==== Cleaning the Nix store ====
|+ Common <code>nix-env</code> Commands
|-
|Searching for packages
|<code>nix-env -qaP '.*packagename.*'</code>
|-
|Installing a package
|<code>nix-env -i packagename</code>
|-
|List installed packages
|<code>nix-env -q</code>
|-
|Uninstall packages
|<code>nix-env -e packagename</code>
|-
|Upgrade packages
|<code>nix-env -u</code>
|}


==== Channels ====
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 ''channels'' are mechanisms for distributing Nix expressions as well as the associated binaries for them; a Nix channel corresponds to a repository in a conventional package management system. Official Nix channels are automatically updated once tests are passed in Nixpkgs' [[Hydra]] instance. It is also possible to create one's own Nix channels, but here we focus the official channels. See the NixOS site for [https://nixos.org/channels/ a full list of official channels].
==== Nix store corruption ====


NixOS is distributed through a number of channels. These NixOS channels can be broadly categorised into ''stable'' and ''unstable'' channels, and ''large'' and ''small'' channels:
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}}.


* Stable/unstable:
==== Valid Nix store names ====
** Stable channels (<code>nixos-17.09</code>) provide conservative updates for fixing bugs and security vulnerabilities, but do not receive major updates after initial release. New stable channels are released every six months.
** Unstable channels (<code>nixos-unstable</code>, <code>nixos-unstable-small</code>) correspond to the main development branch of Nixpkgs, delivering the latest tested updates on a rolling basis.
* Large/small:
** Large channels (<code>nixos-17.09</code>, <code>nixos-unstable</code>) provide binary builds for the full breadth of Nixpkgs.
** Small channels (<code>nixos-17.09-small</code>, <code>nixos-unstable-small</code>) are identical to large channels, but contain fewer binaries. This means they update faster, but require more to be built from source.


Most users will want the stable/large channel, currently <code>nixos-17.09</code>.
{{main|Valid Nix store path names}}


Like packages installed via <code>nix-env</code>, channels are managed at user-level. The following are the most common commands for Nix channel management:
=== Profiles === <!--T:13-->


{| class="wikitable"
<!--T:14-->
|+ Common nix-channel commands
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 <code>/nix/var/nix/profiles</code>, which are in turn symlinked to the user's <code>~/.nix-profile</code>.
|-
|Listing current channels
|<code>nix-channel --list</code>
|-
| Adding a primary channel
|<code><nowiki>nix-channel --add https://nixos.org/channels/channel-name nixos</nowiki></code>
|-
| Adding other channels
|<code><nowiki>nix-channel --add https://some.channel/url my-alias</nowiki></code>
|-
| Remove a channel
|<code>nix-channel --remove channel-alias</code>
|-
| Updating a channel
|<code>nix-channel --update channel-alias</code>
|-
| Updating all channels
|<code>nix-channel --update</code>
|}


Note that updating channels won't cause a rebuild in itself; if you want to update channels and rebuild, you can run <code>nixos rebuild --upgrade</code> to do both in one step.
=== Sandboxing === <!--T:15-->


== Internals ==
<!--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); see [https://nixos.org/nix/manual/#sec-conf-file nix.conf section] in the Nix manual for details.


=== Nix store ===
<!--T:17-->
Sandboxing is enabled by default on Linux, and disabled by default on macOS.
In pull requests for [https://github.com/NixOS/nixpkgs/ Nixpkgs] people are asked to test builds with sandboxing enabled (see <code>Tested using sandboxing</code> in the pull request template) because in [https://nixos.org/hydra/ official Hydra builds] sandboxing is also used.


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 is removed from the store; instead, it symlinks to these packages are added, removed or changed in ''profiles''.
<!--T:18-->
To configure Nix for sandboxing, set <code>sandbox = true</code> in <code>/etc/nix/nix.conf</code>; to configure NixOS for sandboxing set <code>nix.useSandbox = true;</code> in <code>configuration.nix</code>. The <code>nix.useSandbox</code> option is <code>true</code> by default since NixOS 17.09.


=== Profiles ===
=== Alternative Interpreters === <!--T:19-->


In order to construct a coherent user or system environment, Nix symbolically 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 <code>/nix/var/nix/profiles/<code>, which are in turn symlinked to the user's <code>~/.nix-profile</code>.
<!--T:20-->
There is an ongoing effort to reimplement Nix, from the ground up, in Rust.


=== Sandbox builds ===
<!--T:21-->
* [https://cs.tvl.fyi/depot/-/tree/tvix tvix]


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); see [https://nixos.org/nix/manual/#sec-conf-file nix.conf section] in the Nix manual for details.
<!--T:22-->
There is also a community-led fork of Nix 2.18 named Lix, focused on correctness, usability, and growth. While it has also ported some components of Nix to Rust, it is not a ground-up rewrite like Tvix.


Sandboxes are not enabled by default in Nix as there are cases where it makes building packages harder (for example <code>npm install</code> will not work due missing network access).
<!--T:23-->
In pull requests for [https://github.com/NixOS/nixpkgs/ nixpkgs] people are asked to test builds with sandboxing enabled (see <code>Tested using sandboxing</code> in the pull request template) because in [https://nixos.org/hydra/ official hydra builds] sandboxing is also used.
* [https://lix.systems/ lix]


To configure Nix for sandboxing set <code>build-use-sandbox = true;</code> in  <code>/etc/nix/nix.conf</code>; to configure NixOS for sandboxing set <code>nix.useSandbox = true;</code> in <code>configuration.nix</code>.
<!--T:24-->
Earlier attempts can be found on [https://riir-nix.github.io/ riir-nix]


<!--T:25-->
==Notes==
<references />




[[Category:Discussion]]
<!--T:26-->
[[Category:Pedias]]
[[Category:Nix]]
[[Category:Nix]]
[[Category:Incomplete]]
[[Category:Incomplete]]
[[Category:Software]]
</translate>

Latest revision as of 13:28, 19 June 2025

Other languages:
Introduction to Nix

Tools and applications

⤧︎
Disambiguation: This article is about the Nix package manager. Not to be confused with the Nix ecosystem, the Nix language or the 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[1]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 (aka the nix store) that allows for atomic upgrades, rollbacks and concurrent installation of different versions of a package, essentially eliminating dependency hell.

Usage

Installation

On NixOS, Nix is automatically installed.

On other Linux distributions or on macOS, you can install Nix following the installation section of the Nix manual.

Nix commands

The Nix commands are documented in the Nix reference manual: main commands, utilities and experimental commands. Prior to version 2.0 (released in February 2018) there have been different commands.

Configuration

On NixOS, Nix can be configured using the nix option.

Standalone Nix is configured through nix.conf (usually found in /etc/nix/). Details on the available options are found in the Nix reference manual.

You can also configure Nix using Home Manager, which manages declarative environments for a single user. For system-wide configuration, you can use System Manager on Linux and nix-darwin on macOS.

Internals

Nix store

↱︎
This section is a candidate for splitting off into a separate article. The nix store is conceptually separate enough that it warrants a separate article. For more information, consult the related discussion page.

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, symlinks to these packages are added, removed or changed in profiles.

Cleaning the Nix store

For information relating to cleaning the Nix store, refer to NixOS Manual: Chapter - Cleaning the Nix Store.

Nix store corruption

For information relating to fixing a corrupted Nix store, refer to NixOS Manual: Chapter - Nix Store Corruption.

Valid Nix store names

Main article: Valid Nix store path names

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.

There is also a community-led fork of Nix 2.18 named Lix, focused on correctness, usability, and growth. While it has also ported some components of Nix to Rust, it is not a ground-up rewrite like Tvix.

Earlier attempts can be found on riir-nix

Notes

  1. ↑ Values cannot change during computation. Functions always produce the same output if their input does not change.
Retrieved from "https://wiki.nixos.org/w/index.php?title=Nix_(package_manager)&oldid=23219"