Difference between revisions of "Nix package manager"

From NixOS Wiki
Jump to: navigation, search
(Wrote install section.)
m (rollback unauthorized mass edits)
Tag: Rollback
 
(48 intermediate revisions by 18 users not shown)
Line 1: Line 1:
{{Expansion|This article is incomplete.}}
 
  
 
+
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].  
This [[:Category:Discussion|discussion]] article is to cover the usage, internals and configuration of the Nix package manager.
 
  
 
== Usage ==
 
== Usage ==
Line 8: Line 6:
 
=== Installation ===
 
=== Installation ===
  
This section provides an overview of common methods for installing Nix on Non-NixOS distributions.  
+
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]].
 +
 
 +
=== Nix commands ===
 +
 
 +
Since nix 2.0 there is a new style of commands. Those are [https://nixos.org/manual/nix/stable/command-ref/experimental-commands.html documented in the official manual].
 +
See [[Nix command]] for additional information.
 +
 
 +
=== Declarative Configuration ===
 +
The 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 [https://nixos.org/manual/nix/stable/command-ref/conf-file found in 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.
 +
 
 +
[[Home Manager]] is the preferred way to manage declarative environments for a single user.
 +
For system configuration on macOS [https://github.com/LnL7/nix-darwin nix-darwin] is the preferred solution.
 +
 
 +
=== Imperative Operations ===
 +
 
 +
To a large extent, package and environment management in Nix is imperative; user environments - including package installation and removal - is managed with the <code>nix-env</code> command, while <code>nix-channels</code> determine which version of [[Nixpkgs]] is used, and thus which version your packages will have.
  
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]].
+
====  User Environments ====
  
=== Configuration ===
+
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.
  
==== Sandbox builds ====
+
{|  class="wikitable"
 +
|+ Common <code>nix-env</code> Commands
 +
|-
 +
|Searching for packages
 +
|<code>nix search nixpkgs packagename</code>
 +
|-
 +
|Installing a package
 +
|<code>nix-env -iA 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>
 +
|}
  
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/#description-45 build-use-sandbox] in nix manual for details.
+
==== Channels ====
  
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).
+
Nix packages are distributed through a number of Nix channels: mechanisms for distributing Nix expressions as well as the associated binary caches for them. These channels are what determine which versions your packages have, and they can be broadly categorized into ''stable'' and ''unstable'' channels. Most users will want the stable channel, currently <code>nixos-23.11</code>. For more information on channels and how to choose them, see the [[Nix Channels]] article.
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.
 
  
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>.
+
{| class="wikitable"
 +
|+ Common nix-channel commands
 +
|-
 +
|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>
 +
|}
  
 
== Internals ==
 
== Internals ==
  
== Development ==
+
=== Nix store ===
 +
 
 +
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, it symlinks to these packages are added, removed or changed in ''profiles''.
 +
 
 +
=== Profiles ===
  
== History ==
+
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>.
  
=== Common Errors ===
+
=== Sandboxing ===
  
==== Bad configuration option: gssapikexalgorithms ====
+
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.
  
Found when using an SSH binary from Nix on typically RPM-based distros like CentOS, Fedora, Scientific Linux, Redhat, etc. '''The quick fix:''' Just comment out the configuration option in the ssh config file, you probably don't need it.
+
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.
  
==== Desktop Environment does not find .desktop files ====
+
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.
  
IF your DE does not look in <code>$HOME/.nix-profile/share</code> for .desktop files.
+
=== Alternative Interpreters ===
You need to add that path to the <code>XDG_DATA_DIRS</code>, the position reflects precedence so files in earlier directories shadow files in later directories. This can be accomplished in various ways depending on your login manager, see [https://wiki.archlinux.org/index.php/Xprofile Arch wiki: Xprofile] for more information.
 
For example using <code>~/.xprofile</code> as follows:
 
  
<syntaxHighlight lang="console">
+
There is are ongoing effort to port nix to rust.
$ export XDG_DATA_DIRS=$HOME/.nix-profile/share:/usr/local/share:/usr/share
 
</syntaxHighlight>
 
  
Notice that you have to include the default locations on your system, otherwise they will be overwritten. Find out the proper paths using <code>echo $XDG_DATA_DIRS</code>. (Note: <code>export XDG_DATA_DIRS=$HOME/.nix-profile/share:$XDG_DATA_DIRS</code> did not work, XDG_DATA_DIRS ended up containing only <code>$HOME/.nix-profile/share:</code> which isn't even a valid path.)
+
* [https://cs.tvl.fyi/depot/-/tree/tvix tvix]
  
 +
Earlier attempts can be found on [https://riir-nix.github.io/ riir-nix]
  
 +
{{Bottom whitespace}}
  
[[Category:Discussion]]
+
[[Category:Pedias]]
 
[[Category:Nix]]
 
[[Category:Nix]]
 
[[Category:Incomplete]]
 
[[Category:Incomplete]]
 +
[[Category:Software]]

Latest revision as of 10:54, 6 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 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 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.

Nix commands

Since nix 2.0 there is a new style of commands. Those are documented in the official manual. See Nix command for additional information.

Declarative Configuration

The only configuration file officially associated with Nix is nix.conf (usually found in /etc/nix/), 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 manual.

Since most scenarios involve using Nixpkgs, configuration of ~/.config/nixpkgs/config.nix is often also helpful; here package overrides can be specified.

Home Manager is the preferred way to manage declarative environments for a single user. For system configuration on macOS nix-darwin is the preferred solution.

Imperative Operations

To a large extent, package and environment management in Nix is imperative; user environments - including package installation and removal - is managed with the nix-env command, while nix-channels determine which version of Nixpkgs is used, and thus which version your packages will have.

User Environments

Nix offers an imperative package management command line tool - nix-env - which can be used to install packages at the user level. Packages installed using nix-env are only available to the given user, and do not change system state.

Common nix-env Commands
Searching for packages nix search nixpkgs packagename
Installing a package nix-env -iA packagename
List installed packages nix-env -q
Uninstall packages nix-env -e packagename
Upgrade packages nix-env -u

Channels

Nix packages are distributed through a number of Nix channels: mechanisms for distributing Nix expressions as well as the associated binary caches for them. These channels are what determine which versions your packages have, and they can be broadly categorized into stable and unstable channels. Most users will want the stable channel, currently nixos-23.11. For more information on channels and how to choose them, see the Nix Channels article.

Common nix-channel commands
Listing current channels nix-channel --list
Adding a primary channel nix-channel --add https://nixos.org/channels/channel-name nixos
Adding other channels nix-channel --add https://some.channel/url my-alias
Remove a channel nix-channel --remove channel-alias
Updating a channel nix-channel --update channel-alias
Updating all channels nix-channel --update

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 are ongoing effort to port nix to rust.

Earlier attempts can be found on riir-nix