Nix package manager

This article or section needs expansion.

Reason: This article is incomplete. (Discuss in Talk:Nix package manager#)
Please consult the pedia article metapage for guidelines on contributing.

This discussion article is to cover the usage, internals and configuration of the Nix package manager.

Sandbox builds

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 build-use-sandbox in nix manual for details.

Sandboxes are not enabled by default in Nix as there are cases where it makes building packages harder (for example npm install will not work due missing network access). 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.

Depending if you use NixOS or other platforms you can use one of the following methods to enable sandboxing.

Enable sandbox builds in NixOS

In configuration.nix put

nix.useSandbox = true;

Enable sandbox builds on Non-NixOS platforms

In /etc/nix/nix.conf put

build-use-sandbox = true

Nix on Linux

This section is about Nix on Non-NixOS Linux distributions.

Install Nix for a single user

To install Nix from any Linux distribution, use the following two commands (assumes you have the permission to use sudo and you are logged in as the user you want to install Nix for).

$ sudo install -d -m755 -o $USER -g $USER /nix
$ curl https://nixos.org/nix/install | sh

After that being done, you can use all Nix commands as a normal user without any special permissions (for example by using sudo)

Install Nix without root permissions

By using nix-user-chroot or PRoot you can use nix on systems, where you have no permission to create `/nix`. nix-user-chroot is the preferred and faster option. However it might not run on older linux kernels or kernels without user namespace support. With the following command you can test whether your system support user namespaces:

$ unshare --user --pid echo YES

The output should be YES. If the command is absent an alternative is to check the kernel compile options.

$ zgrep CONFIG_USER_NS /proc/config.gz
# On some systems like Debian or Ubuntu the kernel configuration is in a different place
$ grep CONFIG_USER_NS /boot/config-$(uname -r)

If the output of this command is CONFIG_USER_NS=y your system supports user namespaces.

nix-user-chroot

nix-user-chroot will create an environment, in which you can bind mount an directory to /nix. The mountpoint will be only visible within this environment.

nix-user-chroot can be build the following way. This assumes a c compiler and make is installed.

$ git clone https://github.com/lethalman/nix-user-chroot.git
$ cd nix-user-chroot
$ make

The last step created an executable called nix-user-chroot.

nix-user-chroot can be used to install nix. In this example the nix store will be installed to ~/.nix:

$ mkdir -m 0755 ~/.nix
$ ./nix-user-chroot/nix-user-chroot ~/.nix bash

This will start a new shell in which you can run the install script of nix:

$ curl https://nixos.org/nix/install | sh

Note that you can only use nix and the installed programs within the shell started by nix-user-chroot.

PRoot

Precompiled PRoot binaries can be downloaded from here

The following commands will install nix the nix store to ~/.nix

$ chmod +x proot_5.1.1_x86_64_rc2--no-seccomp # first make sure the executable bit is set on the binary
$ mkdir ~/.nix
$ ./proot_5.1.1_x86_64_rc2--no-seccomp ~/.nix

This will start a new shell, where nix can be installed:

$ curl https://nixos.org/nix/install | sh

Note that you can only use nix and the installed programs within the shell started by PRoot.

Common Errors

Bad configuration option: gssapikexalgorithms

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.

Desktop Environment does not find .desktop files

IF your DE does not look in $HOME/.nix-profile/share for .desktop files. You need to add that path to the XDG_DATA_DIRS, 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 Arch wiki: Xprofile for more information. For example using ~/.xprofile as follows:

$ export XDG_DATA_DIRS=$HOME/.nix-profile/share:/usr/local/share:/usr/share

Notice that you have to include the default locations on your system, otherwise they will be overwritten. Find out the proper paths using echo $XDG_DATA_DIRS. (Note: export XDG_DATA_DIRS=$HOME/.nix-profile/share:$XDG_DATA_DIRS did not work, XDG_DATA_DIRS ended up containing only $HOME/.nix-profile/share: which isn't even a valid path.)