Introduction
Nix is a purely functional package manager. This means that it
treats packages like values in purely functional programming languages
such as Haskell — they are built by functions that don’t have
side-effects, and they never change after they have been built. Nix
stores packages in the Nix store, usually the directory
/nix/store
, where each package has its own unique subdirectory such
as
/nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/
where b6gvzjyb2pg0…
is a unique identifier for the package that
captures all its dependencies (it’s a cryptographic hash of the
package’s build dependency graph). This enables many powerful
features.
Multiple versions
You can have multiple versions or variants of a package installed at the same time. This is especially important when different applications have dependencies on different versions of the same package — it prevents the “DLL hell”. Because of the hashing scheme, different versions of a package end up in different paths in the Nix store, so they don’t interfere with each other.
An important consequence is that operations like upgrading or uninstalling an application cannot break other applications, since these operations never “destructively” update or delete files that are used by other packages.
Complete dependencies
Nix helps you make sure that package dependency specifications are complete. In general, when you’re making a package for a package management system like RPM, you have to specify for each package what its dependencies are, but there are no guarantees that this specification is complete. If you forget a dependency, then the package will build and work correctly on your machine if you have the dependency installed, but not on the end user's machine if it's not there.
Since Nix on the other hand doesn’t install packages in “global”
locations like /usr/bin
but in package-specific directories, the
risk of incomplete dependencies is greatly reduced. This is because
tools such as compilers don’t search in per-packages directories such
as /nix/store/5lbfaxb722zp…-openssl-0.9.8d/include
, so if a package
builds correctly on your system, this is because you specified the
dependency explicitly. This takes care of the build-time dependencies.
Once a package is built, runtime dependencies are found by scanning
binaries for the hash parts of Nix store paths (such as r8vvq9kq…
).
This sounds risky, but it works extremely well.
Multi-user support
Nix has multi-user support. This means that non-privileged users can
securely install software. Each user can have a different profile,
a set of packages in the Nix store that appear in the user’s PATH
.
If a user installs a package that another user has already installed
previously, the package won’t be built or downloaded a second time.
At the same time, it is not possible for one user to inject a Trojan
horse into a package that might be used by another user.
Atomic upgrades and rollbacks
Since package management operations never overwrite packages in the Nix store but just add new versions in different paths, they are atomic. So during a package upgrade, there is no time window in which the package has some files from the old version and some files from the new version — which would be bad because a program might well crash if it’s started during that period.
And since packages aren’t overwritten, the old versions are still there after an upgrade. This means that you can roll back to the old version:
$ nix-env --upgrade --attr nixpkgs.some-package
$ nix-env --rollback
Garbage collection
When you uninstall a package like this…
$ nix-env --uninstall firefox
the package isn’t deleted from the system right away (after all, you might want to do a rollback, or it might be in the profiles of other users). Instead, unused packages can be deleted safely by running the garbage collector:
$ nix-collect-garbage
This deletes all packages that aren’t in use by any user profile or by a currently running program.
Functional package language
Packages are built from Nix expressions, which is a simple functional language. A Nix expression describes everything that goes into a package build task (a “derivation”): other packages, sources, the build script, environment variables for the build script, etc. Nix tries very hard to ensure that Nix expressions are deterministic: building a Nix expression twice should yield the same result.
Because it’s a functional language, it’s easy to support building variants of a package: turn the Nix expression into a function and call it any number of times with the appropriate arguments. Due to the hashing scheme, variants don’t conflict with each other in the Nix store.
Transparent source/binary deployment
Nix expressions generally describe how to build a package from source, so an installation action like
$ nix-env --install --attr nixpkgs.firefox
could cause quite a bit of build activity, as not only Firefox but
also all its dependencies (all the way up to the C library and the
compiler) would have to be built, at least if they are not already in the
Nix store. This is a source deployment model. For most users,
building from source is not very pleasant as it takes far too long.
However, Nix can automatically skip building from source and instead
use a binary cache, a web server that provides pre-built
binaries. For instance, when asked to build
/nix/store/b6gvzjyb2pg0…-firefox-33.1
from source, Nix would first
check if the file https://cache.nixos.org/b6gvzjyb2pg0….narinfo
exists, and if so, fetch the pre-built binary referenced from there;
otherwise, it would fall back to building from source.
Nix Packages collection
We provide a large set of Nix expressions containing hundreds of existing Unix packages, the Nix Packages collection (Nixpkgs).
Managing build environments
Nix is extremely useful for developers as it makes it easy to
automatically set up the build environment for a package. Given a Nix
expression that describes the dependencies of your package, the
command nix-shell
will build or download those dependencies if
they’re not already in your Nix store, and then start a Bash shell in
which all necessary environment variables (such as compiler search
paths) are set.
For example, the following command gets all dependencies of the Pan newsreader, as described by its Nix expression:
$ nix-shell '<nixpkgs>' --attr pan
You’re then dropped into a shell where you can edit, build and test the package:
[nix-shell]$ unpackPhase
[nix-shell]$ cd pan-*
[nix-shell]$ configurePhase
[nix-shell]$ buildPhase
[nix-shell]$ ./pan/gui/pan
Portability
Nix runs on Linux and macOS.
NixOS
NixOS is a Linux distribution based on Nix. It uses Nix not just for
package management but also to manage the system configuration (e.g.,
to build configuration files in /etc
). This means, among other
things, that it is easy to roll back the entire configuration of the
system to an earlier state. Also, users can install software without
root privileges. For more information and downloads, see the NixOS
homepage.
License
Nix is released under the terms of the GNU LGPLv2.1 or (at your option) any later version.
Quick Start
This chapter is for impatient people who don't like reading documentation. For more in-depth information you are kindly referred to subsequent chapters.
-
Install Nix:
$ curl -L https://nixos.org/nix/install | sh
The install script will use
sudo
, so make sure you have sufficient rights.For other installation methods, see the detailed installation instructions.
-
Run software without installing it permanently:
$ nix-shell --packages cowsay lolcat
This downloads the specified packages with all their dependencies, and drops you into a Bash shell where the commands provided by those packages are present. This will not affect your normal environment:
[nix-shell:~]$ cowsay Hello, Nix! | lolcat
Exiting the shell will make the programs disappear again:
[nix-shell:~]$ exit $ lolcat lolcat: command not found
-
Search for more packages on search.nixos.org to try them out.
-
Free up storage space:
$ nix-collect-garbage
Installation
This section describes how to install and configure Nix for first-time use.
The current recommended option on Linux and MacOS is multi-user.
Multi-user
This installation offers better sharing, improved isolation, and more security over a single user installation.
This option requires either:
- Linux running systemd, with SELinux disabled
- MacOS
Updating to macOS 15 Sequoia
If you recently updated to macOS 15 Sequoia and are getting
error: the user '_nixbld1' in the group 'nixbld' does not exist
when running Nix commands, refer to GitHub issue NixOS/nix#10892 for instructions to fix your installation without reinstalling.
$ bash <(curl -L https://nixos.org/nix/install) --daemon
Single-user
Single-user is not supported on Mac.
This installation has less requirements than the multi-user install, however it cannot offer equivalent sharing, isolation, or security.
This option is suitable for systems without systemd.
$ bash <(curl -L https://nixos.org/nix/install) --no-daemon
Distributions
The Nix community maintains installers for several distributions.
They can be found in the nix-community/nix-installers
repository.
Supported Platforms
Nix is currently supported on the following platforms:
-
Linux (i686, x86_64, aarch64).
-
macOS (x86_64, aarch64).
Installing a Binary Distribution
Updating to macOS 15 Sequoia
If you recently updated to macOS 15 Sequoia and are getting
error: the user '_nixbld1' in the group 'nixbld' does not exist
when running Nix commands, refer to GitHub issue NixOS/nix#10892 for instructions to fix your installation without reinstalling.
To install the latest version Nix, run the following command:
$ curl -L https://nixos.org/nix/install | sh
This performs the default type of installation for your platform:
- Multi-user:
- Linux with systemd and without SELinux
- macOS
- Single-user:
- Linux without systemd
- Linux with SELinux
We recommend the multi-user installation if it supports your platform and you can authenticate with sudo
.
The installer can configured with various command line arguments and environment variables. To show available command line flags:
$ curl -L https://nixos.org/nix/install | sh -s -- --help
To check what it does and how it can be customised further, download and edit the second-stage installation script.
Installing a pinned Nix version from a URL
Version-specific installation URLs for all Nix versions since 1.11.16 can be found at releases.nixos.org. The directory for each version contains the corresponding SHA-256 hash.
All installation scripts are invoked the same way:
$ export VERSION=2.19.2
$ curl -L https://releases.nixos.org/nix/nix-$VERSION/install | sh
Multi User Installation
The multi-user Nix installation creates system users and a system service for the Nix daemon.
Supported systems:
- Linux running systemd, with SELinux disabled
- macOS
To explicitly instruct the installer to perform a multi-user installation on your system:
$ bash <(curl -L https://nixos.org/nix/install) --daemon
You can run this under your usual user account or root
.
The script will invoke sudo
as needed.
Single User Installation
To explicitly select a single-user installation on your system:
$ bash <(curl -L https://nixos.org/nix/install) --no-daemon
In a single-user installation, /nix
is owned by the invoking user.
The script will invoke sudo
to create /nix
if it doesn’t already exist.
If you don’t have sudo
, manually create /nix
as root
:
$ su root
# mkdir /nix
# chown alice /nix
Installing from a binary tarball
You can also download a binary tarball that contains Nix and all its dependencies:
- Choose a version and system type
- Download and unpack the tarball
- Run the installer
Example
$ pushd $(mktemp -d) $ export VERSION=2.19.2 $ export SYSTEM=x86_64-linux $ curl -LO https://releases.nixos.org/nix/nix-$VERSION/nix-$VERSION-$SYSTEM.tar.xz $ tar xfj nix-$VERSION-$SYSTEM.tar.xz $ cd nix-$VERSION-$SYSTEM $ ./install $ popd
The installer can be customised with the environment variables declared in the file named install-multi-user
.
Native packages for Linux distributions
The Nix community maintains installers for some Linux distributions in their native packaging format(https://nix-community.github.io/nix-installers/).
macOS Installation
We believe we have ironed out how to cleanly support the read-only root file system on modern macOS. New installs will do this automatically.
This section previously detailed the situation, options, and trade-offs, but it now only outlines what the installer does. You don't need to know this to run the installer, but it may help if you run into trouble:
- create a new APFS volume for your Nix store
- update
/etc/synthetic.conf
to direct macOS to create a "synthetic" empty root directory to mount your volume - specify mount options for the volume in
/etc/fstab
rw
: read-writenoauto
: prevent the system from auto-mounting the volume (so the LaunchDaemon mentioned below can control mounting it, and to avoid masking problems with that mounting service).nobrowse
: prevent the Nix Store volume from showing up on your desktop; also keeps Spotlight from spending resources to index this volume
- if you have FileVault enabled
- generate an encryption password
- put it in your system Keychain
- use it to encrypt the volume
- create a system LaunchDaemon to mount this volume early enough in the boot process to avoid problems loading or restoring any programs that need access to your Nix store
Installing Nix from Source
If no binary package is available or if you want to hack on Nix, you can build Nix from its Git repository.
Prerequisites
-
GNU Autoconf (https://www.gnu.org/software/autoconf/) and the autoconf-archive macro collection (https://www.gnu.org/software/autoconf-archive/). These are needed to run the bootstrap script.
-
GNU Make.
-
Bash Shell. The
./configure
script relies on bashisms, so Bash is required. -
A version of GCC or Clang that supports C++20.
-
pkg-config
to locate dependencies. If your distribution does not provide it, you can get it from http://www.freedesktop.org/wiki/Software/pkg-config. -
The OpenSSL library to calculate cryptographic hashes. If your distribution does not provide it, you can get it from https://www.openssl.org.
-
The
libbrotlienc
andlibbrotlidec
libraries to provide implementation of the Brotli compression algorithm. They are available for download from the official repository https://github.com/google/brotli. -
cURL and its library. If your distribution does not provide it, you can get it from https://curl.haxx.se/.
-
The SQLite embedded database library, version 3.6.19 or higher. If your distribution does not provide it, please install it from http://www.sqlite.org/.
-
The Boehm garbage collector (
bdw-gc
) to reduce the evaluator’s memory consumption (optional).To enable it, install
pkgconfig
and the Boehm garbage collector, and pass the flag--enable-gc
toconfigure
. -
The
boost
library of version 1.66.0 or higher. It can be obtained from the official web site https://www.boost.org/. -
The
editline
library of version 1.14.0 or higher. It can be obtained from the its repository https://github.com/troglobit/editline. -
The
libsodium
library for verifying cryptographic signatures of contents fetched from binary caches. It can be obtained from the official web site https://libsodium.org. -
Recent versions of Bison and Flex to build the parser. (This is because Nix needs GLR support in Bison and reentrancy support in Flex.) For Bison, you need version 2.6, which can be obtained from the GNU FTP server. For Flex, you need version 2.5.35, which is available on SourceForge. Slightly older versions may also work, but ancient versions like the ubiquitous 2.5.4a won't.
-
The
libseccomp
is used to provide syscall filtering on Linux. This is an optional dependency and can be disabled passing a--disable-seccomp-sandboxing
option to theconfigure
script (Not recommended unless your system doesn't supportlibseccomp
). To get the library, visit https://github.com/seccomp/libseccomp. -
On 64-bit x86 machines only,
libcpuid
library is used to determine which microarchitecture levels are supported (e.g., as whether to havex86_64-v2-linux
among additional system types). The library is available from its homepage http://libcpuid.sourceforge.net. This is an optional dependency and can be disabled by providing a--disable-cpuid
to theconfigure
script. -
Unless
./configure --disable-unit-tests
is specified, GoogleTest (GTest) and RapidCheck are required, which are available at https://google.github.io/googletest/ and https://github.com/emil-e/rapidcheck respectively.
Obtaining the Source
The most recent sources of Nix can be obtained from its Git
repository. For example, the following
command will check out the latest revision into a directory called
nix
:
$ git clone https://github.com/NixOS/nix
Likewise, specific releases can be obtained from the tags of the repository.
Building Nix from Source
After cloning Nix's Git repository, issue the following commands:
$ autoreconf -vfi
$ ./configure options...
$ make
$ make install
Nix requires GNU Make so you may need to invoke gmake
instead.
The installation path can be specified by passing the --prefix=prefix
to configure
. The default installation directory is /usr/local
. You
can change this to any location you like. You must have write permission
to the prefix path.
Nix keeps its store (the place where packages are stored) in
/nix/store
by default. This can be changed using
--with-store-dir=path
.
Warning
It is best not to change the Nix store from its default, since doing so makes it impossible to use pre-built binaries from the standard Nixpkgs channels — that is, all packages will need to be built from source.
Nix keeps state (such as its database and log files) in /nix/var
by
default. This can be changed using --localstatedir=path
.
Using Nix within Docker
To run the latest stable release of Nix with Docker run the following command:
$ docker run -ti ghcr.io/nixos/nix
Unable to find image 'ghcr.io/nixos/nix:latest' locally
latest: Pulling from ghcr.io/nixos/nix
5843afab3874: Pull complete
b52bf13f109c: Pull complete
1e2415612aa3: Pull complete
Digest: sha256:27f6e7f60227e959ee7ece361f75d4844a40e1cc6878b6868fe30140420031ff
Status: Downloaded newer image for ghcr.io/nixos/nix:latest
35ca4ada6e96:/# nix --version
nix (Nix) 2.3.12
35ca4ada6e96:/# exit
What is included in Nix's Docker image?
The official Docker image is created using pkgs.dockerTools.buildLayeredImage
(and not with Dockerfile
as it is usual with Docker images). You can still
base your custom Docker image on it as you would do with any other Docker
image.
The Docker image is also not based on any other image and includes minimal set of runtime dependencies that are required to use Nix:
- pkgs.nix
- pkgs.bashInteractive
- pkgs.coreutils-full
- pkgs.gnutar
- pkgs.gzip
- pkgs.gnugrep
- pkgs.which
- pkgs.curl
- pkgs.less
- pkgs.wget
- pkgs.man
- pkgs.cacert.out
- pkgs.findutils
Docker image with the latest development version of Nix
To get the latest image that was built by Hydra run the following command:
$ curl -L https://hydra.nixos.org/job/nix/master/dockerImage.x86_64-linux/latest/download/1 | docker load
$ docker run -ti nix:2.5pre20211105
You can also build a Docker image from source yourself:
$ nix build ./\#hydraJobs.dockerImage.x86_64-linux
$ docker load -i ./result/image.tar.gz
$ docker run -ti nix:2.5pre20211105
Security
Nix has two basic security models. First, it can be used in “single-user mode”, which is similar to what most other package management tools do: there is a single user (typically root) who performs all package management operations. All other users can then use the installed packages, but they cannot perform package management operations themselves.
Alternatively, you can configure Nix in “multi-user mode”. In this model, all users can perform package management operations — for instance, every user can install software without requiring root privileges. Nix ensures that this is secure. For instance, it’s not possible for one user to overwrite a package used by another user with a Trojan horse.
Single-User Mode
In single-user mode, all Nix operations that access the database in
prefix/var/nix/db
or modify the Nix store in prefix/store
must be
performed under the user ID that owns those directories. This is
typically root. (If you install from RPM packages, that’s in fact the
default ownership.) However, on single-user machines, it is often
convenient to chown
those directories to your normal user account so
that you don’t have to su
to root all the time.
Multi-User Mode
To allow a Nix store to be shared safely among multiple users, it is important that users are not able to run builders that modify the Nix store or database in arbitrary ways, or that interfere with builds started by other users. If they could do so, they could install a Trojan horse in some package and compromise the accounts of other users.
To prevent this, the Nix store and database are owned by some privileged
user (usually root
) and builders are executed under special user
accounts (usually named nixbld1
, nixbld2
, etc.). When a unprivileged
user runs a Nix command, actions that operate on the Nix store (such as
builds) are forwarded to a Nix daemon running under the owner of the
Nix store/database that performs the operation.
Note
Multi-user mode has one important limitation: only root and a set of trusted users specified in
nix.conf
can specify arbitrary binary caches. So while unprivileged users may install packages from arbitrary Nix expressions, they may not get pre-built binaries.
Setting up the build users
The build users are the special UIDs under which builds are performed.
They should all be members of the build users group nixbld
. This
group should have no other members. The build users should not be
members of any other group. On Linux, you can create the group and users
as follows:
$ groupadd -r nixbld
$ for n in $(seq 1 10); do useradd -c "Nix build user $n" \
-d /var/empty -g nixbld -G nixbld -M -N -r -s "$(which nologin)" \
nixbld$n; done
This creates 10 build users. There can never be more concurrent builds than the number of build users, so you may want to increase this if you expect to do many builds at the same time.
Running the daemon
The Nix daemon should be started as
follows (as root
):
$ nix-daemon
You’ll want to put that line somewhere in your system’s boot scripts.
To let unprivileged users use the daemon, they should set the
NIX_REMOTE
environment variable to
daemon
. So you should put a line like
export NIX_REMOTE=daemon
into the users’ login scripts.
Restricting access
To limit which users can perform Nix operations, you can use the
permissions on the directory /nix/var/nix/daemon-socket
. For instance,
if you want to restrict the use of Nix to the members of a group called
nix-users
, do
$ chgrp nix-users /nix/var/nix/daemon-socket
$ chmod ug=rwx,o= /nix/var/nix/daemon-socket
This way, users who are not in the nix-users
group cannot connect to
the Unix domain socket /nix/var/nix/daemon-socket/socket
, so they
cannot perform Nix operations.
Environment Variables
To use Nix, some environment variables should be set. In particular,
PATH
should contain the directories prefix/bin
and
~/.nix-profile/bin
. The first directory contains the Nix tools
themselves, while ~/.nix-profile
is a symbolic link to the current
user environment (an automatically generated package consisting of
symlinks to installed packages). The simplest way to set the required
environment variables is to include the file
prefix/etc/profile.d/nix.sh
in your ~/.profile
(or similar), like
this:
source prefix/etc/profile.d/nix.sh
NIX_SSL_CERT_FILE
If you need to specify a custom certificate bundle to account for an
HTTPS-intercepting man in the middle proxy, you must specify the path to
the certificate bundle in the environment variable NIX_SSL_CERT_FILE
.
If you don't specify a NIX_SSL_CERT_FILE
manually, Nix will install
and use its own certificate bundle.
Set the environment variable and install Nix
$ export NIX_SSL_CERT_FILE=/etc/ssl/my-certificate-bundle.crt
$ curl -L https://nixos.org/nix/install | sh
In the shell profile and rc files (for example, /etc/bashrc
,
/etc/zshrc
), add the following line:
export NIX_SSL_CERT_FILE=/etc/ssl/my-certificate-bundle.crt
Note
You must not add the export and then do the install, as the Nix installer will detect the presence of Nix configuration, and abort.
If you use the Nix daemon, you should also add the following to
/etc/nix/nix.conf
:
ssl-cert-file = /etc/ssl/my-certificate-bundle.crt
Proxy Environment Variables
The Nix installer has special handling for these proxy-related
environment variables: http_proxy
, https_proxy
, ftp_proxy
,
all_proxy
, no_proxy
, HTTP_PROXY
, HTTPS_PROXY
, FTP_PROXY
,
ALL_PROXY
, NO_PROXY
.
If any of these variables are set when running the Nix installer, then
the installer will create an override file at
/etc/systemd/system/nix-daemon.service.d/override.conf
so nix-daemon
will use them.
Upgrading Nix
Note
These upgrade instructions apply where Nix was installed following the installation instructions in this manual.
Check which Nix version will be installed, for example from one of the release channels such as nixpkgs-unstable
:
$ nix-shell -p nix -I nixpkgs=channel:nixpkgs-unstable --run "nix --version"
nix (Nix) 2.18.1
Warning
Writing to the local store with a newer version of Nix, for example by building derivations with
nix-build
ornix-store --realise
, may change the database schema! Reverting to an older version of Nix may therefore require purging the store database before it can be used.
Linux multi-user
$ sudo su
# nix-env --install --file '<nixpkgs>' --attr nix cacert -I nixpkgs=channel:nixpkgs-unstable
# systemctl daemon-reload
# systemctl restart nix-daemon
macOS multi-user
$ sudo nix-env --install --file '<nixpkgs>' --attr nix cacert -I nixpkgs=channel:nixpkgs-unstable
$ sudo launchctl remove org.nixos.nix-daemon
$ sudo launchctl load /Library/LaunchDaemons/org.nixos.nix-daemon.plist
Single-user all platforms
$ nix-env --install --file '<nixpkgs>' --attr nix cacert -I nixpkgs=channel:nixpkgs-unstable
Uninstalling Nix
Multi User
Removing a multi-user installation depends on the operating system.
Linux
If you are on Linux with systemd:
-
Remove the Nix daemon service:
sudo systemctl stop nix-daemon.service sudo systemctl disable nix-daemon.socket nix-daemon.service sudo systemctl daemon-reload
Remove files created by Nix:
sudo rm -rf /etc/nix /etc/profile.d/nix.sh /etc/tmpfiles.d/nix-daemon.conf /nix ~root/.nix-channels ~root/.nix-defexpr ~root/.nix-profile
Remove build users and their group:
for i in $(seq 1 32); do
sudo userdel nixbld$i
done
sudo groupdel nixbld
There may also be references to Nix in
/etc/bash.bashrc
/etc/bashrc
/etc/profile
/etc/zsh/zshrc
/etc/zshrc
which you may remove.
macOS
Updating to macOS 15 Sequoia
If you recently updated to macOS 15 Sequoia and are getting
error: the user '_nixbld1' in the group 'nixbld' does not exist
when running Nix commands, refer to GitHub issue NixOS/nix#10892 for instructions to fix your installation without reinstalling.
-
If system-wide shell initialisation files haven't been altered since installing Nix, use the backups made by the installer:
sudo mv /etc/zshrc.backup-before-nix /etc/zshrc sudo mv /etc/bashrc.backup-before-nix /etc/bashrc sudo mv /etc/bash.bashrc.backup-before-nix /etc/bash.bashrc
Otherwise, edit
/etc/zshrc
,/etc/bashrc
, and/etc/bash.bashrc
to remove the lines sourcingnix-daemon.sh
, which should look like this:# Nix if [ -e '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh' ]; then . '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh' fi # End Nix
-
Stop and remove the Nix daemon services:
sudo launchctl unload /Library/LaunchDaemons/org.nixos.nix-daemon.plist sudo rm /Library/LaunchDaemons/org.nixos.nix-daemon.plist sudo launchctl unload /Library/LaunchDaemons/org.nixos.darwin-store.plist sudo rm /Library/LaunchDaemons/org.nixos.darwin-store.plist
This stops the Nix daemon and prevents it from being started next time you boot the system.
-
Remove the
nixbld
group and the_nixbuildN
users:sudo dscl . -delete /Groups/nixbld for u in $(sudo dscl . -list /Users | grep _nixbld); do sudo dscl . -delete /Users/$u; done
This will remove all the build users that no longer serve a purpose.
-
Edit fstab using
sudo vifs
to remove the line mounting the Nix Store volume on/nix
, which looks likeUUID=<uuid> /nix apfs rw,noauto,nobrowse,suid,owners
or
LABEL=Nix\040Store /nix apfs rw,nobrowse
by setting the cursor on the respective line using the error keys, and pressing
dd
, and then:wq
to save the file.This will prevent automatic mounting of the Nix Store volume.
-
Edit
/etc/synthetic.conf
to remove thenix
line. If this is the only line in the file you can remove it entirely:if [ -f /etc/synthetic.conf ]; then if [ "$(cat /etc/synthetic.conf)" = "nix" ]; then sudo rm /etc/synthetic.conf else sudo vi /etc/synthetic.conf fi fi
This will prevent the creation of the empty
/nix
directory. -
Remove the files Nix added to your system, except for the store:
sudo rm -rf /etc/nix /var/root/.nix-profile /var/root/.nix-defexpr /var/root/.nix-channels ~/.nix-profile ~/.nix-defexpr ~/.nix-channels
-
Remove the Nix Store volume:
sudo diskutil apfs deleteVolume /nix
This will remove the Nix Store volume and everything that was added to the store.
If the output indicates that the command couldn't remove the volume, you should make sure you don't have an unmounted Nix Store volume. Look for a "Nix Store" volume in the output of the following command:
diskutil list
If you do find a "Nix Store" volume, delete it by running
diskutil deleteVolume
with the store volume'sdiskXsY
identifier.
Note
After you complete the steps here, you will still have an empty
/nix
directory. This is an expected sign of a successful uninstall. The empty/nix
directory will disappear the next time you reboot.You do not have to reboot to finish uninstalling Nix. The uninstall is complete. macOS (Catalina+) directly controls root directories, and its read-only root will prevent you from manually deleting the empty
/nix
mountpoint.
Single User
To remove a single-user installation of Nix, run:
$ rm -rf /nix ~/.nix-channels ~/.nix-defexpr ~/.nix-profile
You might also want to manually remove references to Nix from your ~/.profile
.
Nix Store
The Nix store is an abstraction to store immutable file system data (such as software packages) that can have dependencies on other such data.
There are multiple types of Nix stores with different capabilities, such as the default one on the local filesystem (/nix/store
) or binary caches.
File System Object
Nix uses a simplified model of the file system, which consists of file system objects. Every file system object is one of the following:
-
File
- A possibly empty sequence of bytes for contents
- A single boolean representing the executable permission
-
Directory
Mapping of names to child file system objects
-
An arbitrary string. Nix does not assign any semantics to symbolic links.
File system objects and their children form a tree. A bare file or symlink can be a root file system object.
Nix does not encode any other file system notions such as hard links, permissions, timestamps, or other metadata.
Examples of file system objects
A plain file:
50 B, executable: false
An executable file:
122 KB, executable: true
A symlink:
-> /usr/bin/sh
A directory with contents:
├── bin
│ └── hello: 35 KB, executable: true
└── share
├── info
│ └── hello.info: 36 KB, executable: false
└── man
└── man1
└── hello.1.gz: 790 B, executable: false
A directory that contains a symlink and other directories:
├── bin -> share/go/bin
├── nix-support/
└── share/
Content-Addressing File System Objects
For many operations, Nix needs to calculate a content addresses of a file system object. Usually this is needed as part of content addressing store objects, since store objects always have a root file system object. But some command-line utilities also just work on "raw" file system objects, not part of any store object.
Every content addressing scheme Nix uses ultimately involves feeding data into a hash function, and getting back an opaque fixed-size digest which is deemed a content address. The various methods of content addressing thus differ in how abstract data (in this case, a file system object and its descendents) are fed into the hash function.
Serialising File System Objects
The simplest method is to serialise the entire file system object tree into a single binary string, and then hash that binary string, yielding the content address. In this section we describe the currently-supported methods of serialising file system objects.
Flat
A single file object can just be hashed by its contents. This is not enough information to encode the fact that the file system object is a file, but if we already know that the FSO is a single non-executable file by other means, it is sufficient.
Because the hashed data is just the raw file, as is, this choice is good for compatibility with other systems.
For example, Unix commands like sha256sum
or sha1sum
will produce hashes for single files that match this.
Nix Archive (NAR)
For the other cases of file system objects, especially directories with arbitrary descendents, we need a more complex serialisation format. Examples of such serialisations are the ZIP and TAR file formats. However, for our purposes these formats have two problems:
-
They do not have a canonical serialisation, meaning that given an FSO, there can be many different serialisations. For instance, TAR files can have variable amounts of padding between archive members; and some archive formats leave the order of directory entries undefined. This would be bad because we use serialisation to compute cryptographic hashes over file system objects, and for those hashes to be useful as a content address or for integrity checking, uniqueness is crucial. Otherwise, correct hashes would report false mismatches, and the store would fail to find the content.
-
They store more information than we have in our notion of FSOs, such as time stamps. This can cause FSOs that Nix should consider equal to hash to different values on different machines, just because the dates differ.
-
As a practical consideration, the TAR format is the only truly universal format in the Unix environment. It has many problems, such as an inability to deal with long file names and files larger than 2^33 bytes. Current implementations such as GNU Tar work around these limitations in various ways.
For these reasons, Nix has its very own archive format—the Nix Archive (NAR) format, which is carefully designed to avoid the problems described above.
The exact specification of the Nix Archive format is in protocols/nix-archive.md
Content addressing File System Objects beyond a single serialisation pass
Serialising the entire tree and then hashing that binary string is not the only option for content addressing, however. Another technique is that of a Merkle graph, where previously computed hashes are included in subsequent byte strings to be hashed.
In particular, the Merkle graphs can match the original graph structure of file system objects: we can first hash (serialised) child file system objects, and then hash parent objects using the hashes of their children in the serialisation (to be hashed) of the parent file system objects.
Currently, there is one such Merkle DAG content addressing method supported.
Git (experimental)
Warning
This method is part of the
git-hashing
experimental feature.
Git's file system model is very close to Nix's, and so Git's content addressing method is a pretty good fit. Just as with regular Git, files and symlinks are hashed as git "blobs", and directories are hashed as git "trees".
However, one difference between Nix's and Git's file system model needs special treatment. Plain files, executable files, and symlinks are not differentiated as distinctly addressable objects, but by their context: by the directory entry that refers to them. That means so long as the root object is a directory, there is no problem: every non-directory object is owned by a parent directory, and the entry that refers to it provides the missing information. However, if the root object is not a directory, then we have no way of knowing which one of an executable file, non-executable file, or symlink it is supposed to be.
In response to this, we have decided to treat a bare file as non-executable file. This is similar to do what we do with flat serialisation, which also lacks this information. To avoid an address collision, attempts to hash a bare executable file or symlink will result in an error (just as would happen for flat serialisation also). Thus, Git can encode some, but not all of Nix's "File System Objects", and this sort of content-addressing is likewise partial.
In the future, we may support a Git-like hash for such file system objects, or we may adopt another Merkle DAG format which is capable of representing all Nix file system objects.
Store Object
A Nix store is a collection of store objects with references between them. A store object consists of
- A file system object as data
- A set of store paths as references to other store objects
Store objects are immutable: Once created, they do not change until they are deleted.
Content-Addressing Store Objects
Just like File System Objects, Store Objects can also be content-addressed, unless they are input-addressed.
For store objects, the content address we produce will take the form of a Store Path rather than regular hash. In particular, the content-addressing scheme will ensure that the digest of the store path is solely computed from the
- file system object graph (the root one and its children, if it has any)
- references
- store directory
- name
of the store object, and not any other information, which would not be an intrinsic property of that store object.
For the full specification of the algorithms involved, see the specification of store path digests.
Content addressing each part of a store object
File System Objects
With all currently supported store object content addressing methods, the file system object is always content-addressed first, and then that hash is incorporated into content address computation for the store object.
References
With all currently supported store object content addressing methods, other objects are referred to by their regular (string-encoded-) store paths.
Self-references however cannot be referred to by their path, because we are in the midst of describing how to compute that path!
The alternative would require finding as hash function fixed point, i.e. the solution to an equation in the form
digest = hash(..... || digest || ....)
which is computationally infeasible. As far as we know, this is equivalent to finding a hash collision.
Instead we just have a "has self reference" boolean, which will end up affecting the digest.
Name and Store Directory
These two items affect the digest in a way that is standard for store path digest computations and not specific to content-addressing. Consult the specification of store path digests for further details.
Content addressing Methods
For historical reasons, we don't support all features in all combinations. Each currently supported method of content addressing chooses a single method of file system object hashing, and may offer some restrictions on references. The names and store directories are unrestricted however.
Flat
This uses the corresponding Flat method of file system object content addressing.
References are not supported: store objects with flat hashing and references can not be created.
Text
This also uses the corresponding Flat method of file system object content addressing.
References to other store objects are supported, but self references are not.
This is the only store-object content-addressing method that is not named identically with a corresponding file system object method. It is somewhat obscure, mainly used for "drv files" (derivations serialized as store objects in their "ATerm" file format). Prefer another method if possible.
Nix Archive
This uses the corresponding Nix Archive method of file system object content addressing.
References (to other store objects and self references alike) are supported so long as the hash algorithm is SHA-256, but not (neither kind) otherwise.
Git
Warning
This method is part of the
git-hashing
experimental feature.
This uses the corresponding Git method of file system object content addressing.
References are not supported.
Only SHA-1 is supported at this time. If SHA-256-based Git becomes more widespread, this restriction will be revisited.
Store Path
Example
/nix/store/a040m110amc4h71lds2jmr8qrkj2jhxd-git-2.38.1
A rendered store path
Nix implements references to store objects as store paths.
Think of a store path as an opaque, unique identifier: The only way to obtain store path is by adding or building store objects. A store path will always reference exactly one store object.
Store paths are pairs of
- A 20-byte digest for identification
- A symbolic name for people to read
Example
- Digest:
b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z
- Name:
firefox-33.1
To make store objects accessible to operating system processes, stores have to expose store objects through the file system.
A store path is rendered to a file system path as the concatenation of
- Store directory (typically
/nix/store
) - Path separator (
/
) - Digest rendered in a custom variant of Base32 (20 arbitrary bytes become 32 ASCII characters)
- Hyphen (
-
) - Name
Example
/nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1 |--------| |------------------------------| |----------| store directory digest name
Exactly how the digest is calculated depends on the type of store path. Store path digests are supposed to be opaque, and so for most operations, it is not necessary to know the details. That said, the manual has a full specification of store path digests.
Store Directory
Every Nix store has a store directory.
Not every store can be accessed through the file system. But if the store has a file system representation, the store directory contains the store’s file system objects, which can be addressed by store paths.
This means a store path is not just derived from the referenced store object itself, but depends on the store that the store object is in.
Note
The store directory defaults to
/nix/store
, but is in principle arbitrary.
It is important which store a given store object belongs to: Files in the store object can contain store paths, and processes may read these paths. Nix can only guarantee referential integrity if store paths do not cross store boundaries.
Therefore one can only copy store objects to a different store if
-
The source and target stores' directories match
or
-
The store object in question has no references, that is, contains no store paths
One cannot copy a store object to a store with a different store directory. Instead, it has to be rebuilt, together with all its dependencies. It is in general not enough to replace the store directory string in file contents, as this may render executables unusable by invalidating their internal offsets or checksums.
Nix supports different types of stores:
- Dummy Store
- Experimental Local Overlay Store
- Experimental SSH Store
- Experimental SSH Store with filesystem mounted
- HTTP Binary Cache Store
- Local Binary Cache Store
- Local Daemon Store
- Local Store
- S3 Binary Cache Store
- SSH Store
Store URL format
Stores are specified using a URL-like syntax. For example, the command
# nix path-info --store https://cache.nixos.org/ --json \
/nix/store/a7gvj343m05j2s32xcnwr35v31ynlypr-coreutils-9.1
fetches information about a store path in the HTTP binary cache located at https://cache.nixos.org/, which is a type of store.
Store URLs can specify store settings using URL query strings,
i.e. by appending ?name1=value1&name2=value2&...
to the URL. For
instance,
--store ssh://machine.example.org?ssh-key=/path/to/my/key
tells Nix to access the store on a remote machine via the SSH
protocol, using /path/to/my/key
as the SSH private key. The
supported settings for each store type are documented below.
The special store URL auto
causes Nix to automatically select a
store as follows:
-
Use the local store
/nix/store
if/nix/var/nix
is writable by the current user. -
Otherwise, if
/nix/var/nix/daemon-socket/socket
exists, connect to the Nix daemon listening on that socket. -
Otherwise, on Linux only, use the local chroot store
~/.local/share/nix/root
, which will be created automatically if it does not exist. -
Otherwise, use the local store
/nix/store
.
Dummy Store
Store URL format: dummy://
This store type represents a store that contains no store paths and cannot be written to. It's useful when you want to use the Nix evaluator when no actual Nix store exists, e.g.
# nix eval --store dummy:// --expr '1 + 2'
Settings
-
Size of the in-memory store path metadata cache.
Default:
65536
-
Priority of this store when used as a substituter. A lower value means a higher priority.
Default:
0
-
Logical location of the Nix store, usually
/nix/store
. Note that you can only copy store paths between stores if they have the samestore
setting.Default:
/nix/store
-
Optional system features available on the system this store uses to build derivations.
Example:
"kvm"
Default: machine-specific
-
Whether paths from this store can be used as substitutes even if they are not signed by a key listed in the
trusted-public-keys
setting.Default:
false
-
Whether this store can be queried efficiently for path validity when used as a substituter.
Default:
false
Experimental Local Overlay Store
Warning
This store is part of an experimental feature.
To use this store, make sure the
local-overlay-store
experimental feature is enabled. For example, include the following innix.conf
:extra-experimental-features = local-overlay-store
Store URL format: local-overlay
This store type is a variation of the [local store] designed to leverage Linux's Overlay Filesystem (OverlayFS for short). Just as OverlayFS combines a lower and upper filesystem by treating the upper one as a patch against the lower, the local overlay store combines a lower store with an upper almost-[local store]. ("almost" because while the upper fileystems for OverlayFS is valid on its own, the upper almost-store is not a valid local store on its own because some references will dangle.) To use this store, you will first need to configure an OverlayFS mountpoint appropriately as Nix will not do this for you (though it will verify the mountpoint is configured correctly).
Conceptual parts of a local overlay store
This is a more abstract/conceptual description of the parts of a layered store, an authoritative reference. For more "practical" instructions, see the worked-out example in the next subsection.
The parts of a local overlay store are as follows:
-
Lower store:
Specified with the
lower-store
setting.This is any store implementation that includes a store directory as part of the native operating system filesystem. For example, this could be a [local store], [local daemon store], or even another local overlay store.
The local overlay store never tries to modify the lower store in any way. Something else could modify the lower store, but there are restrictions on this Nix itself requires that this store only grow, and not change in other ways. For example, new store objects can be added, but deleting or modifying store objects is not allowed in general, because that will confuse and corrupt any local overlay store using those objects. (In addition, the underlying filesystem overlay mechanism may impose additional restrictions, see below.)
The lower store must not change while it is mounted as part of an overlay store. To ensure it does not, you might want to mount the store directory read-only (which then requires the [read-only] parameter to be set to
true
).-
Lower store directory:
Specified with
lower-store.real
setting.This is the directory used/exposed by the lower store.
As specified above, Nix requires the local store can only grow not change in other ways. Linux's OverlayFS in addition imposes the further requirement that this directory cannot change at all. That means that, while any local overlay store exists that is using this store as a lower store, this directory must not change.
-
Lower metadata source:
Not directly specified. A consequence of the
lower-store
setting, depending on the type of lower store chosen.This is abstract, just some way to read the metadata of lower store store objects. For example it could be a SQLite database (for the [local store]), or a socket connection (for the [local daemon store]).
This need not be writable. As stated above a local overlay store never tries to modify its lower store. The lower store's metadata is considered part of the lower store, just as the store's file system objects that appear in the store directory are.
-
-
Upper almost-store:
Not directly specified. Instead the constituent parts are independently specified as described below.
This is almost but not quite just a [local store]. That is because taken in isolation, not as part of a local overlay store, by itself, it would appear corrupted. But combined with everything else as part of an overlay local store, it is valid.
-
Upper layer directory:
Specified with
upper-layer
setting.This contains additional store objects (or, strictly speaking, their file system objects that the local overlay store will extend the lower store with).
-
Upper store directory:
Specified with the
real
setting. This the same as the base local store setting, and can also be indirectly specified with theroot
setting.This contains all the store objects from each of the two directories.
The lower store directory and upper layer directory are combined via OverlayFS to create this directory. Nix doesn't do this itself, because it typically wouldn't have the permissions to do so, so it is the responsibility of the user to set this up first. Nix can, however, optionally check that that the OverlayFS mount settings appear as expected, matching Nix's own settings.
-
Upper SQLite database:
Not directly specified. The location of the database instead depends on the
state
setting. It is is always${state}/db
.This contains the metadata of all of the upper layer store objects (everything beyond their file system objects), and also duplicate copies of some lower layer store object's metadta. The duplication is so the metadata for the closure of upper layer store objects can be found entirely within the upper layer. (This allows us to use the same SQL Schema as the [local store]'s SQLite database, as foreign keys in that schema enforce closure metadata to be self-contained in this way.)
-
Example filesystem layout
Here is a worked out example of usage, following the concepts in the previous section.
Say we have the following paths:
-
/mnt/example/merged-store/nix/store
-
/mnt/example/store-a/nix/store
-
/mnt/example/store-b
Then the following store URI can be used to access a local-overlay store at /mnt/example/merged-store
:
local-overlay://?root=/mnt/example/merged-store&lower-store=/mnt/example/store-a&upper-layer=/mnt/example/store-b
The lower store directory is located at /mnt/example/store-a/nix/store
, while the upper layer is at /mnt/example/store-b
.
Before accessing the overlay store you will need to ensure the OverlayFS mount is set up correctly:
mount -t overlay overlay \
-o lowerdir="/mnt/example/store-a/nix/store" \
-o upperdir="/mnt/example/store-b" \
-o workdir="/mnt/example/workdir" \
"/mnt/example/merged-store/nix/store"
Note that OverlayFS requires /mnt/example/workdir
to be on the same volume as the upperdir
.
By default, Nix will check that the mountpoint as been set up correctly and fail with an error if it has not.
You can override this behaviour by passing check-mount=false
if you need to.
Settings
-
Check that the overlay filesystem is correctly mounted.
Nix does not manage the overlayfs mount point itself, but the correct functioning of the overlay store does depend on this mount point being set up correctly. Rather than just assume this is the case, check that the lowerdir and upperdir options are what we expect them to be. This check is on by default, but can be disabled if needed.
Default:
true
-
directory where Nix will store log files.
Default:
/nix/var/log/nix
-
Store URL for the lower store. The default is
auto
(i.e. use the Nix daemon or/nix/store
directly).Must be a store with a store dir on the file system. Must be used as OverlayFS lower layer for this store's store dir.
Default: empty
-
Size of the in-memory store path metadata cache.
Default:
65536
-
Priority of this store when used as a substituter. A lower value means a higher priority.
Default:
0
-
Allow this store to be opened when its database is on a read-only filesystem.
Normally Nix will attempt to open the store database in read-write mode, even for querying (when write access is not needed), causing it to fail if the database is on a read-only filesystem.
Enable read-only mode to disable locking and open the SQLite database with the
immutable
parameter set.Warning Do not use this unless the filesystem is read-only.
Using it when the filesystem is writable can cause incorrect query results or corruption errors if the database is changed by another process. While the filesystem the database resides on might appear to be read-only, consider whether another user or system might have write access to it.
Default:
false
-
Physical path of the Nix store.
Default:
/nix/store
-
Script or other executable to run when overlay filesystem needs remounting.
This is occasionally necessary when deleting a store path that exists in both upper and lower layers. In such a situation, bypassing OverlayFS and deleting the path in the upper layer directly is the only way to perform the deletion without creating a "whiteout". However this causes the OverlayFS kernel data structures to get out-of-sync, and can lead to 'stale file handle' errors; remounting solves the problem.
The store directory is passed as an argument to the invoked executable.
Default: empty
-
Whether store paths copied into this store should have a trusted signature.
Default:
true
-
Directory prefixed to all other paths.
Default: ``
-
Directory where Nix will store state.
Default:
/dummy
-
Logical location of the Nix store, usually
/nix/store
. Note that you can only copy store paths between stores if they have the samestore
setting.Default:
/nix/store
-
Optional system features available on the system this store uses to build derivations.
Example:
"kvm"
Default: machine-specific
-
Whether paths from this store can be used as substitutes even if they are not signed by a key listed in the
trusted-public-keys
setting.Default:
false
-
Directory containing the OverlayFS upper layer for this store's store dir.
Default: empty
-
Whether this store can be queried efficiently for path validity when used as a substituter.
Default:
false
Experimental SSH Store
Store URL format: ssh-ng://[username@]hostname
Experimental store type that allows full access to a Nix store on a remote machine.
Settings
-
The public host key of the remote machine.
Default: empty
-
Whether to enable SSH compression.
Default:
false
-
Maximum age of a connection before it is closed.
Default:
4294967295
-
Maximum number of concurrent connections to the Nix daemon.
Default:
1
-
Size of the in-memory store path metadata cache.
Default:
65536
-
Priority of this store when used as a substituter. A lower value means a higher priority.
Default:
0
-
Path to the
nix-daemon
executable on the remote machine.Default:
nix-daemon
-
Store URL to be used on the remote machine. The default is
auto
(i.e. use the Nix daemon or/nix/store
directly).Default: empty
-
Path to the SSH private key used to authenticate to the remote machine.
Default: empty
-
Logical location of the Nix store, usually
/nix/store
. Note that you can only copy store paths between stores if they have the samestore
setting.Default:
/nix/store
-
Optional system features available on the system this store uses to build derivations.
Example:
"kvm"
Default: machine-specific
-
Whether paths from this store can be used as substitutes even if they are not signed by a key listed in the
trusted-public-keys
setting.Default:
false
-
Whether this store can be queried efficiently for path validity when used as a substituter.
Default:
false
Experimental SSH Store with filesystem mounted
Warning
This store is part of an experimental feature.
To use this store, make sure the
mounted-ssh-store
experimental feature is enabled. For example, include the following innix.conf
:extra-experimental-features = mounted-ssh-store
Store URL format: mounted-ssh-ng://[username@]hostname
Experimental store type that allows full access to a Nix store on a remote machine, and additionally requires that store be mounted in the local file system.
The mounting of that store is not managed by Nix, and must by managed manually. It could be accomplished with SSHFS or NFS, for example.
The local file system is used to optimize certain operations. For example, rather than serializing Nix archives and sending over the Nix channel, we can directly access the file system data via the mount-point.
The local file system is also used to make certain operations possible that wouldn't otherwise be. For example, persistent GC roots can be created if they reside on the same file system as the remote store: the remote side will create the symlinks necessary to avoid race conditions.
Settings
-
The public host key of the remote machine.
Default: empty
-
Whether to enable SSH compression.
Default:
false
-
directory where Nix will store log files.
Default:
/nix/var/log/nix
-
Maximum age of a connection before it is closed.
Default:
4294967295
-
Maximum number of concurrent connections to the Nix daemon.
Default:
1
-
Size of the in-memory store path metadata cache.
Default:
65536
-
Priority of this store when used as a substituter. A lower value means a higher priority.
Default:
0
-
Physical path of the Nix store.
Default:
/nix/store
-
Path to the
nix-daemon
executable on the remote machine.Default:
nix-daemon
-
Store URL to be used on the remote machine. The default is
auto
(i.e. use the Nix daemon or/nix/store
directly).Default: empty
-
Directory prefixed to all other paths.
Default: ``
-
Path to the SSH private key used to authenticate to the remote machine.
Default: empty
-
Directory where Nix will store state.
Default:
/dummy
-
Logical location of the Nix store, usually
/nix/store
. Note that you can only copy store paths between stores if they have the samestore
setting.Default:
/nix/store
-
Optional system features available on the system this store uses to build derivations.
Example:
"kvm"
Default: machine-specific
-
Whether paths from this store can be used as substitutes even if they are not signed by a key listed in the
trusted-public-keys
setting.Default:
false
-
Whether this store can be queried efficiently for path validity when used as a substituter.
Default:
false
HTTP Binary Cache Store
Store URL format: http://...
, https://...
This store allows a binary cache to be accessed via the HTTP protocol.
Settings
-
NAR compression method (
xz
,bzip2
,gzip
,zstd
, ornone
).Default:
xz
-
The preset level to be used when compressing NARs. The meaning and accepted values depend on the compression method selected.
-1
specifies that the default compression level should be used.Default:
-1
-
Whether to index DWARF debug info files by build ID. This allows
dwarffs
to fetch debug info on demandDefault:
false
-
Path to a local cache of NARs fetched from this binary cache, used by commands such as
nix store cat
.Default: empty
-
Enable multi-threaded compression of NARs. This is currently only available for
xz
andzstd
.Default:
false
-
Size of the in-memory store path metadata cache.
Default:
65536
-
Priority of this store when used as a substituter. A lower value means a higher priority.
Default:
0
-
Path to the secret key used to sign the binary cache.
Default: empty
-
Logical location of the Nix store, usually
/nix/store
. Note that you can only copy store paths between stores if they have the samestore
setting.Default:
/nix/store
-
Optional system features available on the system this store uses to build derivations.
Example:
"kvm"
Default: machine-specific
-
Whether paths from this store can be used as substitutes even if they are not signed by a key listed in the
trusted-public-keys
setting.Default:
false
-
Whether this store can be queried efficiently for path validity when used as a substituter.
Default:
false
-
Whether to write a JSON file that lists the files in each NAR.
Default:
false
Local Binary Cache Store
Store URL format: file://
path
This store allows reading and writing a binary cache stored in path in the local filesystem. If path does not exist, it will be created.
For example, the following builds or downloads nixpkgs#hello
into
the local store and then copies it to the binary cache in
/tmp/binary-cache
:
# nix copy --to file:///tmp/binary-cache nixpkgs#hello
Settings
-
NAR compression method (
xz
,bzip2
,gzip
,zstd
, ornone
).Default:
xz
-
The preset level to be used when compressing NARs. The meaning and accepted values depend on the compression method selected.
-1
specifies that the default compression level should be used.Default:
-1
-
Whether to index DWARF debug info files by build ID. This allows
dwarffs
to fetch debug info on demandDefault:
false
-
Path to a local cache of NARs fetched from this binary cache, used by commands such as
nix store cat
.Default: empty
-
Enable multi-threaded compression of NARs. This is currently only available for
xz
andzstd
.Default:
false
-
Size of the in-memory store path metadata cache.
Default:
65536
-
Priority of this store when used as a substituter. A lower value means a higher priority.
Default:
0
-
Path to the secret key used to sign the binary cache.
Default: empty
-
Logical location of the Nix store, usually
/nix/store
. Note that you can only copy store paths between stores if they have the samestore
setting.Default:
/nix/store
-
Optional system features available on the system this store uses to build derivations.
Example:
"kvm"
Default: machine-specific
-
Whether paths from this store can be used as substitutes even if they are not signed by a key listed in the
trusted-public-keys
setting.Default:
false
-
Whether this store can be queried efficiently for path validity when used as a substituter.
Default:
false
-
Whether to write a JSON file that lists the files in each NAR.
Default:
false
Local Daemon Store
Store URL format: daemon
, unix://
path
This store type accesses a Nix store by talking to a Nix daemon
listening on the Unix domain socket path. The store pseudo-URL
daemon
is equivalent to unix:///nix/var/nix/daemon-socket/socket
.
Settings
-
directory where Nix will store log files.
Default:
/nix/var/log/nix
-
Maximum age of a connection before it is closed.
Default:
4294967295
-
Maximum number of concurrent connections to the Nix daemon.
Default:
1
-
Size of the in-memory store path metadata cache.
Default:
65536
-
Priority of this store when used as a substituter. A lower value means a higher priority.
Default:
0
-
Physical path of the Nix store.
Default:
/nix/store
-
Directory prefixed to all other paths.
Default: ``
-
Directory where Nix will store state.
Default:
/dummy
-
Logical location of the Nix store, usually
/nix/store
. Note that you can only copy store paths between stores if they have the samestore
setting.Default:
/nix/store
-
Optional system features available on the system this store uses to build derivations.
Example:
"kvm"
Default: machine-specific
-
Whether paths from this store can be used as substitutes even if they are not signed by a key listed in the
trusted-public-keys
setting.Default:
false
-
Whether this store can be queried efficiently for path validity when used as a substituter.
Default:
false
Local Store
Store URL format: local
, root
This store type accesses a Nix store in the local filesystem directly
(i.e. not via the Nix daemon). root is an absolute path that is
prefixed to other directories such as the Nix store directory. The
store pseudo-URL local
denotes a store that uses /
as its root
directory.
A store that uses a root other than /
is called a chroot
store. With such stores, the store directory is "logically" still
/nix/store
, so programs stored in them can only be built and
executed by chroot
-ing into root. Chroot stores only support
building and running on Linux when mount namespaces
and user namespaces
are
enabled.
For example, the following uses /tmp/root
as the chroot environment
to build or download nixpkgs#hello
and then execute it:
# nix run --store /tmp/root nixpkgs#hello
Hello, world!
Here, the "physical" store location is /tmp/root/nix/store
, and
Nix's store metadata is in /tmp/root/nix/var/nix/db
.
It is also possible, but not recommended, to change the "logical"
location of the Nix store from its default of /nix/store
. This makes
it impossible to use default substituters such as
https://cache.nixos.org/
, and thus you may have to build everything
locally. Here is an example:
# nix build --store 'local?store=/tmp/my-nix/store&state=/tmp/my-nix/state&log=/tmp/my-nix/log' nixpkgs#hello
Settings
-
directory where Nix will store log files.
Default:
/nix/var/log/nix
-
Size of the in-memory store path metadata cache.
Default:
65536
-
Priority of this store when used as a substituter. A lower value means a higher priority.
Default:
0
-
Allow this store to be opened when its database is on a read-only filesystem.
Normally Nix will attempt to open the store database in read-write mode, even for querying (when write access is not needed), causing it to fail if the database is on a read-only filesystem.
Enable read-only mode to disable locking and open the SQLite database with the
immutable
parameter set.Warning Do not use this unless the filesystem is read-only.
Using it when the filesystem is writable can cause incorrect query results or corruption errors if the database is changed by another process. While the filesystem the database resides on might appear to be read-only, consider whether another user or system might have write access to it.
Default:
false
-
Physical path of the Nix store.
Default:
/nix/store
-
Whether store paths copied into this store should have a trusted signature.
Default:
true
-
Directory prefixed to all other paths.
Default: ``
-
Directory where Nix will store state.
Default:
/dummy
-
Logical location of the Nix store, usually
/nix/store
. Note that you can only copy store paths between stores if they have the samestore
setting.Default:
/nix/store
-
Optional system features available on the system this store uses to build derivations.
Example:
"kvm"
Default: machine-specific
-
Whether paths from this store can be used as substitutes even if they are not signed by a key listed in the
trusted-public-keys
setting.Default:
false
-
Whether this store can be queried efficiently for path validity when used as a substituter.
Default:
false
S3 Binary Cache Store
Store URL format: s3://
bucket-name
This store allows reading and writing a binary cache stored in an AWS S3 (or S3-compatible service) bucket. This store shares many idioms with the HTTP Binary Cache Store.
For AWS S3, the binary cache URL for a bucket named example-nix-cache
will be exactly s3://example-nix-cache.
For S3 compatible binary caches, consult that cache's documentation.
Anonymous reads to your S3-compatible binary cache
If your binary cache is publicly accessible and does not require authentication, it is simplest to use the [HTTP Binary Cache Store] rather than S3 Binary Cache Store with https://example-nix-cache.s3.amazonaws.com instead of s3://example-nix-cache.
Your bucket will need a bucket policy like the following to be accessible:
{
"Id": "DirectReads",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowDirectReads",
"Action": [
"s3:GetObject",
"s3:GetBucketLocation"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::example-nix-cache",
"arn:aws:s3:::example-nix-cache/*"
],
"Principal": "*"
}
]
}
Authentication
Nix will use the default credential provider chain for authenticating requests to Amazon S3.
Note that this means Nix will read environment variables and files with different idioms than with Nix's own settings, as implemented by the AWS SDK. Consult the documentation linked above for further details.
Authenticated reads to your S3 binary cache
Your bucket will need a bucket policy allowing the desired users to perform the s3:GetObject
and s3:GetBucketLocation
action on all objects in the bucket.
The anonymous policy given above can be updated to have a restricted Principal
to support this.
Authenticated writes to your S3-compatible binary cache
Your account will need an IAM policy to support uploading to the bucket:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "UploadToCache",
"Effect": "Allow",
"Action": [
"s3:AbortMultipartUpload",
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket",
"s3:ListBucketMultipartUploads",
"s3:ListMultipartUploadParts",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::example-nix-cache",
"arn:aws:s3:::example-nix-cache/*"
]
}
]
}
Examples
With bucket policies and authentication set up as described above, uploading works via nix copy
(experimental).
-
To upload with a specific credential profile for Amazon S3:
$ nix copy nixpkgs.hello \ --to 's3://example-nix-cache?profile=cache-upload®ion=eu-west-2'
-
To upload to an S3-compatible binary cache:
$ nix copy nixpkgs.hello --to \ 's3://example-nix-cache?profile=cache-upload&scheme=https&endpoint=minio.example.com'
Settings
-
Size (in bytes) of each part in multi-part uploads.
Default:
5242880
-
NAR compression method (
xz
,bzip2
,gzip
,zstd
, ornone
).Default:
xz
-
The preset level to be used when compressing NARs. The meaning and accepted values depend on the compression method selected.
-1
specifies that the default compression level should be used.Default:
-1
-
The URL of the endpoint of an S3-compatible service such as MinIO. Do not specify this setting if you're using Amazon S3.
Note
This endpoint must support HTTPS and will use path-based addressing instead of virtual host based addressing.
Default: empty
-
Whether to index DWARF debug info files by build ID. This allows
dwarffs
to fetch debug info on demandDefault:
false
-
Path to a local cache of NARs fetched from this binary cache, used by commands such as
nix store cat
.Default: empty
-
Compression method for
log/*
files. It is recommended to use a compression method supported by most web browsers (e.g.brotli
).Default: empty
-
Compression method for
.ls
files.Default: empty
-
Whether to use multi-part uploads.
Default:
false
-
Compression method for
.narinfo
files.Default: empty
-
Enable multi-threaded compression of NARs. This is currently only available for
xz
andzstd
.Default:
false
-
Size of the in-memory store path metadata cache.
Default:
65536
-
Priority of this store when used as a substituter. A lower value means a higher priority.
Default:
0
-
The name of the AWS configuration profile to use. By default Nix will use the
default
profile.Default: empty
-
The region of the S3 bucket. If your bucket is not in
us–east-1
, you should always explicitly specify the region parameter.Default:
us-east-1
-
The scheme used for S3 requests,
https
(default) orhttp
. This option allows you to disable HTTPS for binary caches which don't support it.Note
HTTPS should be used if the cache might contain sensitive information.
Default: empty
-
Path to the secret key used to sign the binary cache.
Default: empty
-
Logical location of the Nix store, usually
/nix/store
. Note that you can only copy store paths between stores if they have the samestore
setting.Default:
/nix/store
-
Optional system features available on the system this store uses to build derivations.
Example:
"kvm"
Default: machine-specific
-
Whether paths from this store can be used as substitutes even if they are not signed by a key listed in the
trusted-public-keys
setting.Default:
false
-
Whether this store can be queried efficiently for path validity when used as a substituter.
Default:
false
-
Whether to write a JSON file that lists the files in each NAR.
Default:
false
SSH Store
Store URL format: ssh://[username@]hostname
This store type allows limited access to a remote store on another machine via SSH.
Settings
-
The public host key of the remote machine.
Default: empty
-
Whether to enable SSH compression.
Default:
false
-
Maximum number of concurrent SSH connections.
Default:
1
-
Size of the in-memory store path metadata cache.
Default:
65536
-
Priority of this store when used as a substituter. A lower value means a higher priority.
Default:
0
-
Path to the
nix-store
executable on the remote machine.Default:
nix-store
-
Store URL to be used on the remote machine. The default is
auto
(i.e. use the Nix daemon or/nix/store
directly).Default: empty
-
Path to the SSH private key used to authenticate to the remote machine.
Default: empty
-
Logical location of the Nix store, usually
/nix/store
. Note that you can only copy store paths between stores if they have the samestore
setting.Default:
/nix/store
-
Optional system features available on the system this store uses to build derivations.
Example:
"kvm"
Default: machine-specific
-
Whether paths from this store can be used as substitutes even if they are not signed by a key listed in the
trusted-public-keys
setting.Default:
false
-
Whether this store can be queried efficiently for path validity when used as a substituter.
Default:
false
Nix Language
The Nix language is designed for conveniently creating and composing derivations – precise descriptions of how contents of existing files are used to derive new files.
Tip
These pages are written as a reference. If you are learning Nix, nix.dev has a good introduction to the Nix language.
The language is:
-
domain-specific
It comes with built-in functions to integrate with the Nix store, which manages files and performs the derivations declared in the Nix language.
-
declarative
There is no notion of executing sequential steps. Dependencies between operations are established only through data.
-
pure
Values cannot change during computation. Functions always produce the same output if their input does not change.
-
functional
Functions are like any other value. Functions can be assigned to names, taken as arguments, or returned by functions.
-
lazy
Values are only computed when they are needed.
-
dynamically typed
Type errors are only detected when expressions are evaluated.
Overview
This is an incomplete overview of language features, by example.
Example | Description |
---|---|
Basic values (primitives) |
|
|
A string |
|
A multi-line string. Strips common prefixed whitespace. Evaluates to |
|
A comment. |
|
String interpolation (expands to |
|
|
|
Null value |
|
An integer |
|
|
|
An absolute path |
|
A path relative to the file containing this Nix expression |
|
A home path. Evaluates to the |
|
A lookup path for Nix files. Value determined by |
Compound values |
|
|
An attribute set with attributes named |
|
A nested set, equivalent to |
|
A recursive set, equivalent to |
|
Lists with three elements. |
Operators |
|
|
String concatenation |
|
Integer addition |
|
Equality test (evaluates to |
|
Inequality test (evaluates to |
|
Boolean negation |
|
Attribute selection (evaluates to |
|
Attribute selection with default (evaluates to |
|
Merge two sets (attributes in the right-hand set taking precedence) |
Control structures |
|
|
|
|
Assertion check (evaluates to |
|
Variable definition. See |
|
Add all attributes from the given set to the scope (evaluates to See |
|
Adds the variables to the current scope (attribute set or |
|
Adds the attributes, from the attribute set in parentheses, to the current scope (attribute set or |
Functions (lambdas) |
|
|
A function that expects an integer and returns it increased by 1. |
|
Curried function, equivalent to |
|
A function call (evaluates to 101) |
|
A function bound to a variable and subsequently called by name (evaluates to 103) |
|
A function that expects a set with required attributes |
|
A function that expects a set with required attribute |
|
A function that expects a set with required attributes |
|
A function that expects a set with required attributes |
Built-in functions |
|
|
Load and return Nix expression in given file. See import. |
|
Apply a function to every element of a list (evaluates to |
Data Types
Every value in the Nix language has one of the following types:
Primitives
Integer
An integer in the Nix language is a signed 64-bit integer.
Non-negative integers can be expressed as integer literals.
Negative integers are created with the arithmetic negation operator.
The function builtins.isInt
can be used to determine if a value is an integer.
Float
A float in the Nix language is a 64-bit IEEE 754 floating-point number.
Most non-negative floats can be expressed as float literals.
Negative floats are created with the arithmetic negation operator.
The function builtins.isFloat
can be used to determine if a value is a float.
Boolean
A boolean in the Nix language is one of true or false.
These values are available as attributes of builtins
as builtins.true
and builtins.false
.
The function builtins.isBool
can be used to determine if a value is a boolean.
String
A string in the Nix language is an immutable, finite-length sequence of bytes, along with a string context. Nix does not assume or support working natively with character encodings.
String values without string context can be expressed as string literals.
The function builtins.isString
can be used to determine if a value is a string.
Path
A path in the Nix language is an immutable, finite-length sequence of bytes starting with /
, representing a POSIX-style, canonical file system path.
Path values are distinct from string values, even if they contain the same sequence of bytes.
Operations that produce paths will simplify the result as the standard C function realpath
would, except that there is no symbolic link resolution.
Paths are suitable for referring to local files, and are often preferable over strings.
- Path values do not contain trailing or duplicate slashes,
.
, or..
. - Relative path literals are automatically resolved relative to their base directory.
- Tooling can recognize path literals and provide additional features, such as autocompletion, refactoring automation and jump-to-file.
A file is not required to exist at a given path in order for that path value to be valid, but a path that is converted to a string with string interpolation or string-and-path concatenation must resolve to a readable file or directory which will be copied into the Nix store.
For instance, evaluating "${./foo.txt}"
will cause foo.txt
from the same directory to be copied into the Nix store and result in the string "/nix/store/<hash>-foo.txt"
.
Operations such as import
can also expect a path to resolve to a readable file or directory.
Note
The Nix language assumes that all input files will remain unchanged while evaluating a Nix expression. For example, assume you used a file path in an interpolated string during a
nix repl
session. Later in the same session, after having changed the file contents, evaluating the interpolated string with the file path again might not return a new store path, since Nix might not re-read the file contents. Use:r
to reset the repl as needed.
Path values can be expressed as path literals.
The function builtins.isPath
can be used to determine if a value is a path.
Null
There is a single value of type null in the Nix language.
This value is available as an attribute on the builtins
attribute set as builtins.null
.
Compound values
Attribute set
An attribute set can be constructed with an attribute set literal.
The function builtins.isAttrs
can be used to determine if a value is an attribute set.
List
A list can be constructed with a list literal.
The function builtins.isList
can be used to determine if a value is a list.
Function
A function can be constructed with a function expression.
The function builtins.isFunction
can be used to determine if a value is a function.
External
An external value is an opaque value created by a Nix plugin. Such a value can be substituted in Nix expressions but only created and used by plugin code.
String context
Note
This is an advanced topic. The Nix language is designed to be used without the programmer consciously dealing with string contexts or even knowing what they are.
A string in the Nix language is not just a sequence of characters like strings in other languages. It is actually a pair of a sequence of characters and a string context. The string context is an (unordered) set of string context elements.
The purpose of string contexts is to collect non-string values attached to strings via string concatenation, string interpolation, and similar operations. The idea is that a user can combine together values to create a build instructions for derivations without manually keeping track of where they come from. Then the Nix language implicitly does that bookkeeping to efficiently obtain the closure of derivation inputs.
Note
String contexts are not explicitly manipulated in idiomatic Nix language code.
String context elements come in different forms:
-
A string context element of this type is a deriving path. They can be either of type constant or output, which correspond to the types of deriving paths.
-
Constant string context elements
Example
builtins.storePath
creates a string with a single constant string context element:builtins.getContext (builtins.storePath "/nix/store/wkhdf9jinag5750mqlax6z2zbwhqb76n-hello-2.10")
evaluates to
{ "/nix/store/wkhdf9jinag5750mqlax6z2zbwhqb76n-hello-2.10" = { path = true; }; }
-
Output string context elements
Example
The behavior of string contexts are best demonstrated with a built-in function that is still experimental:
builtins.outputOf
. This example will not work with stable Nix!builtins.getContext (builtins.outputOf (builtins.storePath "/nix/store/fvchh9cvcr7kdla6n860hshchsba305w-hello-2.12.drv") "out")
evaluates to
{ "/nix/store/fvchh9cvcr7kdla6n860hshchsba305w-hello-2.12.drv" = { outputs = [ "out" ]; }; }
-
-
derivation deep is an advanced feature intended to be used with the
exportReferencesGraph
derivation attribute. A derivation deep string context element is a derivation path, and refers to both its outputs and the entire build closure of that derivation: all its outputs, all the other derivations the given derivation depends on, and all the outputs of those.Example
The best way to illustrate derivation deep string contexts is with
builtins.addDrvOutputDependencies
. Take a regular constant string context element pointing to a derivation, and transform it into a "Derivation deep" string context element.builtins.getContext (builtins.addDrvOutputDependencies (builtins.storePath "/nix/store/fvchh9cvcr7kdla6n860hshchsba305w-hello-2.12.drv"))
evaluates to
{ "/nix/store/fvchh9cvcr7kdla6n860hshchsba305w-hello-2.12.drv" = { allOutputs = true; }; }
Inspecting string contexts
Most basically, builtins.hasContext
will tell whether a string has a non-empty context.
When more granular information is needed, builtins.getContext
can be used.
It creates an attribute set representing the string context, which can be inspected as usual.
Clearing string contexts
buitins.unsafeDiscardStringContext
will make a copy of a string, but with an empty string context.
The returned string can be used in more ways, e.g. by operators that require the string context to be empty.
The requirement to explicitly discard the string context in such use cases helps ensure that string context elements are not lost by mistake.
The "unsafe" marker is only there to remind that Nix normally guarantees that dependencies are tracked, whereas the returned string has lost them.
Constructing string contexts
builtins.appendContext
will create a copy of a string, but with additional string context elements.
The context is specified explicitly by an attribute set in the format that builtins.hasContext
produces.
A string with arbitrary contexts can be made like this:
- Create a string with the desired string context elements. (The contents of the string do not matter.)
- Dump its context with
builtins.getContext
. - Combine it with a base string and repeated
builtins.appendContext
calls.
Language Constructs
This section covers syntax and semantics of the Nix language.
Basic Literals
String
Strings can be written in three ways.
The most common way is to enclose the string between double quotes, e.g., "foo bar"
.
Strings can span multiple lines.
The results of other expressions can be included into a string by enclosing them in ${ }
, a feature known as string interpolation.
The following must be escaped to represent them within a string, by prefixing with a backslash (\
):
-
Double quote (
"
)Example
"\""
"""
-
Backslash (
\
)Example
"\\"
"\"
-
Dollar sign followed by an opening curly bracket (
${
) – "dollar-curly"Example
"\${"
"${"
The newline, carriage return, and tab characters can be written as \n
, \r
and \t
, respectively.
A "double-dollar-curly" ($${
) can be written literally.
Example
"$${"
"$${"
String values are output on the terminal with Nix-specific escaping. Strings written to files will contain the characters encoded by the escaping.
The second way to write string literals is as an indented string, which is enclosed between pairs of double single-quotes (''
), like so:
''
This is the first line.
This is the second line.
This is the third line.
''
This kind of string literal intelligently strips indentation from the start of each line. To be precise, it strips from each line a number of spaces equal to the minimal indentation of the string as a whole (disregarding the indentation of empty lines). For instance, the first and second line are indented two spaces, while the third line is indented four spaces. Thus, two spaces are stripped from each line, so the resulting string is
"This is the first line.\nThis is the second line.\n This is the third line.\n"
Note
Whitespace and newline following the opening
''
is ignored if there is no non-whitespace text on the initial line.
Warning
Prefixed tab characters are not stripped.
Example
The following indented string is prefixed with tabs:
'' all: @echo hello ''
"\tall:\n\t\t@echo hello\n"
Indented strings support string interpolation.
The following must be escaped to represent them in an indented string:
-
$
is escaped by prefixing it with two single quotes (''
)Example
'' ''$ ''
"$\n"
-
''
is escaped by prefixing it with one single quote ('
)Example
'' ''' ''
"''\n"
These special characters are escaped as follows:
- Linefeed (
\n
):''\n
- Carriage return (
\r
):''\r
- Tab (
\t
):''\t
''\
escapes any other character.
A "double-dollar-curly" ($${
) can be written literally.
Example
'' $${ ''
"$\${\n"
Indented strings are primarily useful in that they allow multi-line
string literals to follow the indentation of the enclosing Nix
expression, and that less escaping is typically necessary for
strings representing languages such as shell scripts and
configuration files because ''
is much less common than "
.
Example:
stdenv.mkDerivation {
...
postInstall =
''
mkdir $out/bin $out/etc
cp foo $out/bin
echo "Hello World" > $out/etc/foo.conf
${if enableBar then "cp bar $out/bin" else ""}
'';
...
}
Finally, as a convenience, URIs as defined in appendix B of
RFC 2396 can be written as
is, without quotes. For instance, the string
"http://example.org/foo.tar.bz2"
can also be written as
http://example.org/foo.tar.bz2
.
Number
Numbers, which can be integers (like 123
) or floating point
(like 123.43
or .27e13
).
See arithmetic and comparison operators for semantics.
Path
Paths can be expressed by path literals such as ./builder.sh
.
A path literal must contain at least one slash to be recognised as such.
For instance, builder.sh
is not a path:
it's parsed as an expression that selects the attribute sh
from the variable builder
.
Path literals are resolved relative to their base directory. Path literals may also refer to absolute paths by starting with a slash.
Note
Absolute paths make expressions less portable. In the case where a function translates a path literal into an absolute path string for a configuration file, it is recommended to write a string literal instead. This avoids some confusion about whether files at that location will be used during evaluation. It also avoids unintentional situations where some function might try to copy everything at the location into the store.
If the first component of a path is a ~
, it is interpreted such that the rest of the path were relative to the user's home directory.
For example, ~/foo
would be equivalent to /home/edolstra/foo
for a user whose home directory is /home/edolstra
.
Path literals that start with ~
are not allowed in pure evaluation.
Path literals can also include string interpolation, besides being interpolated into other expressions.
At least one slash (/
) must appear before any interpolated expression for the result to be recognized as a path.
a.${foo}/b.${bar}
is a syntactically valid number division operation.
./a.${foo}/b.${bar}
is a path.
Lookup path literals such as <nixpkgs>
also resolve to path values.
List
Lists are formed by enclosing a whitespace-separated list of values between square brackets. For example,
[ 123 ./foo.nix "abc" (f { x = y; }) ]
defines a list of four elements, the last being the result of a call to
the function f
. Note that function calls have to be enclosed in
parentheses. If they had been omitted, e.g.,
[ 123 ./foo.nix "abc" f { x = y; } ]
the result would be a list of five elements, the fourth one being a function and the fifth being a set.
Note that lists are only lazy in values, and they are strict in length.
Elements in a list can be accessed using builtins.elemAt
.
Attribute Set
An attribute set is a collection of name-value-pairs called attributes.
Attribute sets are written enclosed in curly brackets ({ }
).
Attribute names and attribute values are separated by an equal sign (=
).
Each value can be an arbitrary expression, terminated by a semicolon (;
)
An attribute name is a string without context, and is denoted by a name (an identifier or string literal).
Syntax
attrset →
{
{ name=
expr;
}}
Attributes can appear in any order. An attribute name may only occur once in each attribute set.
Example
This defines an attribute set with attributes named:
x
with the value123
, an integertext
with the value"Hello"
, a stringy
where the value is the result of applying the functionf
to the attribute set{ bla = 456; }
{ x = 123; text = "Hello"; y = f { bla = 456; }; }
Attributes in nested attribute sets can be written using attribute paths.
Syntax
attrset →
{
{ attrpath=
expr;
}}
An attribute path is a dot-separated list of names.
Syntax
attrpath = name {
.
name }
Example
{ a.b.c = 1; a.b.d = 2; }
{ a = { b = { c = 1; d = 2; }; }; }
Attribute names can also be set implicitly by using the inherit
keyword.
Example
{ inherit (builtins) true; }
{ true = true; }
Attributes can be accessed with the .
operator.
Example:
{ a = "Foo"; b = "Bar"; }.a
This evaluates to "Foo"
.
It is possible to provide a default value in an attribute selection using the or
keyword.
Example:
{ a = "Foo"; b = "Bar"; }.c or "Xyzzy"
{ a = "Foo"; b = "Bar"; }.c.d.e.f.g or "Xyzzy"
will both evaluate to "Xyzzy"
because there is no c
attribute in the set.
You can use arbitrary double-quoted strings as attribute names:
{ "$!@#?" = 123; }."$!@#?"
let bar = "bar"; in
{ "foo ${bar}" = 123; }."foo ${bar}"
Both will evaluate to 123
.
Attribute names support string interpolation:
let bar = "foo"; in
{ foo = 123; }.${bar}
let bar = "foo"; in
{ ${bar} = 123; }.foo
Both will evaluate to 123
.
In the special case where an attribute name inside of a set declaration
evaluates to null
(which is normally an error, as null
cannot be coerced to
a string), that attribute is simply not added to the set:
{ ${if foo then "bar" else null} = true; }
This will evaluate to {}
if foo
evaluates to false
.
A set that has a __functor
attribute whose value is callable (i.e. is
itself a function or a set with a __functor
attribute whose value is
callable) can be applied as if it were a function, with the set itself
passed in first , e.g.,
let add = { __functor = self: x: x + self.x; };
inc = add // { x = 1; };
in inc 1
evaluates to 2
. This can be used to attach metadata to a function
without the caller needing to treat it specially, or to implement a form
of object-oriented programming, for example.
Recursive sets
Recursive sets are like normal attribute sets, but the attributes can refer to each other.
rec-attrset =
rec {
[ name=
expr;
]
...}
Example:
rec {
x = y;
y = 123;
}.x
This evaluates to 123
.
Note that without rec
the binding x = y;
would
refer to the variable y
in the surrounding scope, if one exists, and
would be invalid if no such variable exists. That is, in a normal
(non-recursive) set, attributes are not added to the lexical scope; in a
recursive set, they are.
Recursive sets of course introduce the danger of infinite recursion. For example, the expression
rec {
x = y;
y = x;
}.x
will crash with an infinite recursion encountered
error message.
Let-expressions
A let-expression allows you to define local variables for an expression.
let-in =
let
[ identifier = expr ]...in
expr
Example:
let
x = "foo";
y = "bar";
in x + y
This evaluates to "foobar"
.
Inheriting attributes
When defining an attribute set or in a let-expression it is often convenient to copy variables from the surrounding lexical scope (e.g., when you want to propagate attributes).
This can be shortened using the inherit
keyword.
Example:
let x = 123; in
{
inherit x;
y = 456;
}
is equivalent to
let x = 123; in
{
x = x;
y = 456;
}
and both evaluate to { x = 123; y = 456; }
.
Note
This works because
x
is added to the lexical scope by thelet
construct.
It is also possible to inherit attributes from another attribute set.
Example:
In this fragment from all-packages.nix
,
graphviz = (import ../tools/graphics/graphviz) {
inherit fetchurl stdenv libpng libjpeg expat x11 yacc;
inherit (xorg) libXaw;
};
xorg = {
libX11 = ...;
libXaw = ...;
...
}
libpng = ...;
libjpg = ...;
...
the set used in the function call to the function defined in
../tools/graphics/graphviz
inherits a number of variables from the
surrounding scope (fetchurl
... yacc
), but also inherits libXaw
(the X Athena Widgets) from the xorg
set.
Summarizing the fragment
...
inherit x y z;
inherit (src-set) a b c;
...
is equivalent to
...
x = x; y = y; z = z;
a = src-set.a; b = src-set.b; c = src-set.c;
...
when used while defining local variables in a let-expression or while defining a set.
In a let
expression, inherit
can be used to selectively bring specific attributes of a set into scope. For example
let
x = { a = 1; b = 2; };
inherit (builtins) attrNames;
in
{
names = attrNames x;
}
is equivalent to
let
x = { a = 1; b = 2; };
in
{
names = builtins.attrNames x;
}
both evaluate to { names = [ "a" "b" ]; }
.
Functions
Functions have the following form:
pattern: body
The pattern specifies what the argument of the function must look like, and binds variables in the body to (parts of) the argument. There are three kinds of patterns:
-
If a pattern is a single identifier, then the function matches any argument. Example:
let negate = x: !x; concat = x: y: x + y; in if negate true then concat "foo" "bar" else ""
Note that
concat
is a function that takes one argument and returns a function that takes another argument. This allows partial parameterisation (i.e., only filling some of the arguments of a function); e.g.,map (concat "foo") [ "bar" "bla" "abc" ]
evaluates to
[ "foobar" "foobla" "fooabc" ]
. -
A set pattern of the form
{ name1, name2, …, nameN }
matches a set containing the listed attributes, and binds the values of those attributes to variables in the function body. For example, the function{ x, y, z }: z + y + x
can only be called with a set containing exactly the attributes
x
,y
andz
. No other attributes are allowed. If you want to allow additional arguments, you can use an ellipsis (...
):{ x, y, z, ... }: z + y + x
This works on any set that contains at least the three named attributes.
It is possible to provide default values for attributes, in which case they are allowed to be missing. A default value is specified by writing
name ? e
, where e is an arbitrary expression. For example,{ x, y ? "foo", z ? "bar" }: z + y + x
specifies a function that only requires an attribute named
x
, but optionally acceptsy
andz
. -
An
@
-pattern provides a means of referring to the whole value being matched:args@{ x, y, z, ... }: z + y + x + args.a
but can also be written as:
{ x, y, z, ... } @ args: z + y + x + args.a
Here
args
is bound to the argument as passed, which is further matched against the pattern{ x, y, z, ... }
. The@
-pattern makes mainly sense with an ellipsis(...
) as you can access attribute names asa
, usingargs.a
, which was given as an additional attribute to the function.Warning
args@
binds the nameargs
to the attribute set that is passed to the function. In particular,args
does not include any default values specified with?
in the function's set pattern.For instance
let f = args@{ a ? 23, ... }: [ a args ]; in f {}
is equivalent to
let f = args @ { ... }: [ (args.a or 23) args ]; in f {}
and both expressions will evaluate to:
[ 23 {} ]
Note that functions do not have names. If you want to give them a name, you can bind them to an attribute, e.g.,
let concat = { x, y }: x + y;
in concat { x = "foo"; y = "bar"; }
Conditionals
Conditionals look like this:
if e1 then e2 else e3
where e1 is an expression that should evaluate to a Boolean value
(true
or false
).
Assertions
Assertions are generally used to check that certain requirements on or between features and dependencies hold. They look like this:
assert e1; e2
where e1 is an expression that should evaluate to a Boolean value. If
it evaluates to true
, e2 is returned; otherwise expression
evaluation is aborted and a backtrace is printed.
Here is a Nix expression for the Subversion package that shows how assertions can be used:.
{ localServer ? false
, httpServer ? false
, sslSupport ? false
, pythonBindings ? false
, javaSwigBindings ? false
, javahlBindings ? false
, stdenv, fetchurl
, openssl ? null, httpd ? null, db4 ? null, expat, swig ? null, j2sdk ? null
}:
assert localServer -> db4 != null; ①
assert httpServer -> httpd != null && httpd.expat == expat; ②
assert sslSupport -> openssl != null && (httpServer -> httpd.openssl == openssl); ③
assert pythonBindings -> swig != null && swig.pythonSupport;
assert javaSwigBindings -> swig != null && swig.javaSupport;
assert javahlBindings -> j2sdk != null;
stdenv.mkDerivation {
name = "subversion-1.1.1";
...
openssl = if sslSupport then openssl else null; ④
...
}
The points of interest are:
-
This assertion states that if Subversion is to have support for local repositories, then Berkeley DB is needed. So if the Subversion function is called with the
localServer
argument set totrue
but thedb4
argument set tonull
, then the evaluation fails.Note that
->
is the logical implication Boolean operation. -
This is a more subtle condition: if Subversion is built with Apache (
httpServer
) support, then the Expat library (an XML library) used by Subversion should be same as the one used by Apache. This is because in this configuration Subversion code ends up being linked with Apache code, and if the Expat libraries do not match, a build- or runtime link error or incompatibility might occur. -
This assertion says that in order for Subversion to have SSL support (so that it can access
https
URLs), an OpenSSL library must be passed. Additionally, it says that if Apache support is enabled, then Apache's OpenSSL should match Subversion's. (Note that if Apache support is not enabled, we don't care about Apache's OpenSSL.) -
The conditional here is not really related to assertions, but is worth pointing out: it ensures that if SSL support is disabled, then the Subversion derivation is not dependent on OpenSSL, even if a non-
null
value was passed. This prevents an unnecessary rebuild of Subversion if OpenSSL changes.
With-expressions
A with-expression,
with e1; e2
introduces the set e1 into the lexical scope of the expression e2. For instance,
let as = { x = "foo"; y = "bar"; };
in with as; x + y
evaluates to "foobar"
since the with
adds the x
and y
attributes
of as
to the lexical scope in the expression x + y
. The most common
use of with
is in conjunction with the import
function. E.g.,
with (import ./definitions.nix); ...
makes all attributes defined in the file definitions.nix
available as
if they were defined locally in a let
-expression.
The bindings introduced by with
do not shadow bindings introduced by
other means, e.g.
let a = 3; in with { a = 1; }; let a = 4; in with { a = 2; }; ...
establishes the same scope as
let a = 1; in let a = 2; in let a = 3; in let a = 4; in ...
Variables coming from outer with
expressions are shadowed:
with { a = "outer"; };
with { a = "inner"; };
a
Does evaluate to "inner"
.
Comments
-
Inline comments start with
#
and run until the end of the line.Example
# A number 2 # Equals 1 + 1
2
-
Block comments start with
/*
and run until the next occurrence of*/
.Example
/* Block comments can span multiple lines. */ "hello"
"hello"
This means that block comments cannot be nested.
Example
/* /* nope */ */ 1
error: syntax error, unexpected '*' at «string»:1:15: 1| /* /* nope */ * | ^
Consider escaping nested comments and unescaping them in post-processing.
Example
/* /* nested *\/ */ 1
1
Identifiers
An identifier is an ASCII character sequence that:
- Starts with a letter (
a-z
,A-Z
) or underscore (_
) - Can contain any number of:
- Letters (
a-z
,A-Z
) - Digits (
0-9
) - Underscores (
_
) - Apostrophes (
'
) - Hyphens (
-
)
- Letters (
- Is not one of the keywords
Syntax
identifier ~
[A-Za-z_][A-Za-z0-9_'-]*
Names
A name can be an identifier or a string literal.
Syntax
name → identifier | string
Names are used in attribute sets, let
bindings, and [inherit
](./syntax.md#inheriting attributes).
Keywords
These keywords are reserved and cannot be used as identifiers:
Note
The Nix language evaluator currently allows
or
to be used as a name in some contexts, for backwards compatibility reasons. Users are advised not to rely on this.There are long-standing issues with how
or
is parsed as a name, which can't be resolved without making a breaking change to the language.
Scoping rules
Nix is statically scoped, but with multiple scopes and shadowing rules.
-
primary scope: explicitly-bound variables
-
secondary scope: implicitly-bound variables
Primary scope takes precedence over secondary scope.
See with
for a detailed example.
String interpolation
String interpolation is a language feature where a string, path, or attribute name can contain expressions enclosed in ${ }
(dollar-sign with curly brackets).
Such a construct is called interpolated string, and the expression inside is an interpolated expression.
Examples
String
Rather than writing
"--with-freetype2-library=" + freetype + "/lib"
(where freetype
is a derivation), you can instead write
"--with-freetype2-library=${freetype}/lib"
The latter is automatically translated to the former.
A more complicated example (from the Nix expression for Qt):
configureFlags = "
-system-zlib -system-libpng -system-libjpeg
${if openglSupport then "-dlopen-opengl
-L${mesa}/lib -I${mesa}/include
-L${libXmu}/lib -I${libXmu}/include" else ""}
${if threadSupport then "-thread" else "-no-thread"}
";
Note that Nix expressions and strings can be arbitrarily nested;
in this case the outer string contains various interpolated expressions that themselves contain strings (e.g., "-thread"
), some of which in turn contain interpolated expressions (e.g., ${mesa}
).
To write a literal ${
in an regular string, escape it with a backslash (\
).
Example
"echo \${PATH}"
"echo ${PATH}"
To write a literal ${
in an indented string, escape it with two single quotes (''
).
Example
'' echo ''${PATH} ''
"echo ${PATH}\n"
$${
can be written literally in any string.
Example
In Make,
$
in file names or recipes is represented as$$
, see GNUmake
: Basics of Variable Reference. This can be expressed directly in the Nix language strings:'' MAKEVAR = Hello all: @export BASHVAR=world; echo $(MAKEVAR) $${BASHVAR} ''
"MAKEVAR = Hello\nall:\n\t@export BASHVAR=world; echo $(MAKEVAR) $\${BASHVAR}\n"
See the documentation on strings for details.
Path
Rather than writing
./. + "/" + foo + "-" + bar + ".nix"
or
./. + "/${foo}-${bar}.nix"
you can instead write
./${foo}-${bar}.nix
Attribute name
Attribute names can be interpolated strings.
Example
let name = "foo"; in { ${name} = 123; }
{ foo = 123; }
Attributes can be selected with interpolated strings.
Example
let name = "foo"; in { foo = 123; }.${name}
123
Interpolated expression
An expression that is interpolated must evaluate to one of the following:
-
a string
-
a path
-
an attribute set that has a
__toString
attribute or anoutPath
attribute__toString
must be a function that takes the attribute set itself and returns a stringoutPath
must be a string
This includes derivations or flake inputs (experimental).
A string interpolates to itself.
A path in an interpolated expression is first copied into the Nix store, and the resulting string is the store path of the newly created store object.
Example
$ mkdir foo
Reference the empty directory in an interpolated expression:
"${./foo}"
"/nix/store/2hhl2nz5v0khbn06ys82nrk99aa1xxdw-foo"
A derivation interpolates to the store path of its first output.
Example
let pkgs = import <nixpkgs> {}; in "${pkgs.hello}"
"/nix/store/4xpfqf29z4m8vbhrqcz064wfmb46w5r7-hello-2.12.1"
An attribute set interpolates to the return value of the function in the __toString
applied to the attribute set itself.
Example
let a = { value = 1; __toString = self: toString (self.value + 1); }; in "${a}"
"2"
An attribute set also interpolates to the value of its outPath
attribute.
Example
let a = { outPath = "foo"; }; in "${a}"
"foo"
If both __toString
and outPath
are present in an attribute set, __toString
takes precedence.
Example
let a = { __toString = _: "yes"; outPath = throw "no"; }; in "${a}"
"yes"
If neither is present, an error is thrown.
Example
let a = {}; in "${a}"
error: cannot coerce a set to a string: { } at «string»:4:2: 3| in 4| "${a}" | ^
Lookup path
Syntax
lookup-path =
<
identifier [/
identifier ]...>
A lookup path is an identifier with an optional path suffix that resolves to a path value if the identifier matches a search path entry.
The value of a lookup path is determined by builtins.nixPath
.
See builtins.findFile
for details on lookup path resolution.
Example
<nixpkgs>
/nix/var/nix/profiles/per-user/root/channels/nixpkgs
Example
<nixpkgs/nixos>
/nix/var/nix/profiles/per-user/root/channels/nixpkgs/nixos
Operators
Name | Syntax | Associativity | Precedence |
---|---|---|---|
Attribute selection | attrset . attrpath [ or expr ] | none | 1 |
Function application | func expr | left | 2 |
Arithmetic negation | - number | none | 3 |
Has attribute | attrset ? attrpath | none | 4 |
List concatenation | list ++ list | right | 5 |
Multiplication | number * number | left | 6 |
Division | number / number | left | 6 |
Subtraction | number - number | left | 7 |
Addition | number + number | left | 7 |
String concatenation | string + string | left | 7 |
Path concatenation | path + path | left | 7 |
Path and string concatenation | path + string | left | 7 |
String and path concatenation | string + path | left | 7 |
Logical negation (NOT ) | ! bool | none | 8 |
Update | attrset // attrset | right | 9 |
Less than | expr < expr | none | 10 |
Less than or equal to | expr <= expr | none | 10 |
Greater than | expr > expr | none | 10 |
Greater than or equal to | expr >= expr | none | 10 |
Equality | expr == expr | none | 11 |
Inequality | expr != expr | none | 11 |
Logical conjunction (AND ) | bool && bool | left | 12 |
Logical disjunction (OR ) | bool || bool | left | 13 |
Logical implication | bool -> bool | right | 14 |
Pipe operator (experimental) | expr |> func | left | 15 |
Pipe operator (experimental) | func <| expr | right | 15 |
Attribute selection
Syntax
attrset
.
attrpath [or
expr ]
Select the attribute denoted by attribute path attrpath from attribute set attrset.
If the attribute doesn’t exist, return the expr after or
if provided, otherwise abort evaluation.
Has attribute
Syntax
attrset
?
attrpath
Test whether attribute set attrset contains the attribute denoted by attrpath. The result is a Boolean value.
See also: builtins.hasAttr
After evaluating attrset and attrpath, the computational complexity is O(log(n)) for n attributes in the attrset
Arithmetic
Numbers are type-compatible: Pure integer operations will always return integers, whereas any operation involving at least one floating point number return a floating point number.
See also Comparison and Equality.
The +
operator is overloaded to also work on strings and paths.
String concatenation
Syntax
string
+
string
Concatenate two strings and merge their string contexts.
Path concatenation
Syntax
path
+
path
Concatenate two paths. The result is a path.
Path and string concatenation
Syntax
path + string
Concatenate path with string. The result is a path.
Note
The string must not have a string context that refers to a store path.
String and path concatenation
Syntax
string + path
Concatenate string with path. The result is a string.
Important
The file or directory at path must exist and is copied to the store. The path appears in the result as the corresponding store path.
Update
Syntax
attrset1 // attrset2
Update attribute set attrset1 with names and values from attrset2.
The returned attribute set will have all of the attributes in attrset1 and attrset2. If an attribute name is present in both, the attribute value from the latter is taken.
Comparison
Comparison is
- arithmetic for numbers
- lexicographic for strings and paths
- item-wise lexicographic for lists: elements at the same index in both lists are compared according to their type and skipped if they are equal.
All comparison operators are implemented in terms of <
, and the following equivalencies hold:
comparison | implementation |
---|---|
a <= b | ! ( b < a ) |
a > b | b < a |
a >= b | ! ( a < b ) |
Equality
- Attribute sets and lists are compared recursively, and therefore are fully evaluated.
- Comparison of functions always returns
false
. - Numbers are type-compatible, see arithmetic operators.
- Floating point numbers only differ up to a limited precision.
Logical implication
Equivalent to !
b1 ||
b2.
Pipe operators
- a
|>
b is equivalent to b a - a
<|
b is equivalent to a b
Example
nix-repl> 1 |> builtins.add 2 |> builtins.mul 3 9 nix-repl> builtins.add 1 <| builtins.mul 2 <| 3 7
Warning
This syntax is part of an experimental feature and may change in future releases.
To use this syntax, make sure the
pipe-operators
experimental feature is enabled. For example, include the following innix.conf
:extra-experimental-features = pipe-operators
Built-ins
This section lists the values and functions built into the Nix language evaluator.
All built-ins are available through the global builtins
constant.
Some built-ins are also exposed directly in the global scope:
derivation attrs
derivation is described in its own section.
-
abort s
-
Abort Nix expression evaluation and print the error message s.
-
add e1 e2
-
Return the sum of the numbers e1 and e2.
-
addDrvOutputDependencies s
-
Create a copy of the given string where a single constant string context element is turned into a derivation deep string context element.
The store path that is the constant string context element should point to a valid derivation, and end in
.drv
.The original string context element must not be empty or have multiple elements, and it must not have any other type of element other than a constant or derivation deep element. The latter is supported so this function is idempotent.
This is the opposite of
builtins.unsafeDiscardOutputDependency
. -
all pred list
-
Return
true
if the function pred returnstrue
for all elements of list, andfalse
otherwise. -
any pred list
-
Return
true
if the function pred returnstrue
for at least one element of list, andfalse
otherwise. -
attrNames set
-
Return the names of the attributes in the set set in an alphabetically sorted list. For instance,
builtins.attrNames { y = 1; x = "foo"; }
evaluates to[ "x" "y" ]
. -
attrValues set
-
Return the values of the attributes in the set set in the order corresponding to the sorted attribute names.
-
baseNameOf x
-
Return the base name of either a path value x or a string x, depending on which type is passed, and according to the following rules.
For a path value, the base name is considered to be the part of the path after the last directory separator, including any file extensions. This is the simple case, as path values don't have trailing slashes.
When the argument is a string, a more involved logic applies. If the string ends with a
/
, only this one final slash is removed.After this, the base name is returned as previously described, assuming
/
as the directory separator. (Note that evaluation must be platform independent.)This is somewhat similar to the GNU
basename
command, but GNUbasename
will strip any number of trailing slashes. -
bitAnd e1 e2
-
Return the bitwise AND of the integers e1 and e2.
-
bitOr e1 e2
-
Return the bitwise OR of the integers e1 and e2.
-
bitXor e1 e2
-
Return the bitwise XOR of the integers e1 and e2.
-
break v
-
In debug mode (enabled using
--debugger
), pause Nix expression evaluation and enter the REPL. Otherwise, return the argumentv
. -
builtins
(set) -
Contains all the built-in functions and values.
Since built-in functions were added over time, testing for attributes in
builtins
can be used for graceful fallback on older Nix installations:# if hasContext is not available, we assume `s` has a context if builtins ? hasContext then builtins.hasContext s else true
-
catAttrs attr list
-
Collect each attribute named attr from a list of attribute sets. Attrsets that don't contain the named attribute are ignored. For example,
builtins.catAttrs "a" [{a = 1;} {b = 0;} {a = 2;}]
evaluates to
[1 2]
. -
ceil double
-
Converts an IEEE-754 double-precision floating-point number (double) to the next higher integer.
If the datatype is neither an integer nor a "float", an evaluation error will be thrown.
-
compareVersions s1 s2
-
Compare two strings representing versions and return
-1
if version s1 is older than version s2,0
if they are the same, and1
if s1 is newer than s2. The version comparison algorithm is the same as the one used bynix-env -u
. -
concatLists lists
-
Concatenate a list of lists into a single list.
-
concatMap f list
-
This function is equivalent to
builtins.concatLists (map f list)
but is more efficient. -
concatStringsSep separator list
-
Concatenate a list of strings with a separator between each element, e.g.
concatStringsSep "/" ["usr" "local" "bin"] == "usr/local/bin"
. -
convertHash args
-
Return the specified representation of a hash string, based on the attributes presented in args:
-
hash
The hash to be converted. The hash format is detected automatically.
-
hashAlgo
The algorithm used to create the hash. Must be one of
"md5"
"sha1"
"sha256"
"sha512"
The attribute may be omitted when
hash
is an SRI hash or when the hash is prefixed with the hash algorithm name followed by a colon. That<hashAlgo>:<hashBody>
syntax is supported for backwards compatibility with existing tooling. -
toHashFormat
The format of the resulting hash. Must be one of
"base16"
"nix32"
"base32"
(deprecated alias for"nix32"
)"base64"
"sri"
The result hash is the toHashFormat representation of the hash hash.
Example
Convert a SHA256 hash in Base16 to SRI:
builtins.convertHash { hash = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"; toHashFormat = "sri"; hashAlgo = "sha256"; }
"sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU="
Example
Convert a SHA256 hash in SRI to Base16:
builtins.convertHash { hash = "sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU="; toHashFormat = "base16"; }
"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
Example
Convert a hash in the form
<hashAlgo>:<hashBody>
in Base16 to SRI:builtins.convertHash { hash = "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"; toHashFormat = "sri"; }
"sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU="
-
-
currentSystem
(string) -
The value of the
eval-system
or elsesystem
configuration option.It can be used to set the
system
attribute forbuiltins.derivation
such that the resulting derivation can be built on the same system that evaluates the Nix expression:builtins.derivation { # ... system = builtins.currentSystem; }
It can be overridden in order to create derivations for different system than the current one:
$ nix-instantiate --system "mips64-linux" --eval --expr 'builtins.currentSystem' "mips64-linux"
Note
Not available in pure evaluation mode.
-
currentTime
(integer) -
Return the Unix time at first evaluation. Repeated references to that name will re-use the initially obtained value.
Example:
$ nix repl Welcome to Nix 2.15.1 Type :? for help. nix-repl> builtins.currentTime 1683705525 nix-repl> builtins.currentTime 1683705525
The store path of a derivation depending on
currentTime
will differ for each evaluation, unless both evaluatebuiltins.currentTime
in the same second.Note
Not available in pure evaluation mode.
-
deepSeq e1 e2
-
This is like
seq e1 e2
, except that e1 is evaluated deeply: if it’s a list or set, its elements or attributes are also evaluated recursively. -
dirOf s
-
Return the directory part of the string s, that is, everything before the final slash in the string. This is similar to the GNU
dirname
command. -
div e1 e2
-
Return the quotient of the numbers e1 and e2.
-
elem x xs
-
Return
true
if a value equal to x occurs in the list xs, andfalse
otherwise. -
elemAt xs n
-
Return element n from the list xs. Elements are counted starting from 0. A fatal error occurs if the index is out of bounds.
-
false
(Boolean) -
Primitive value.
It can be returned by comparison operators and used in conditional expressions.
The name
false
is not special, and can be shadowed:nix-repl> let false = 1; in false 1
-
fetchClosure args
-
Note
This function is only available if the
fetch-closure
experimental feature is enabled.For example, include the following in
nix.conf
:extra-experimental-features = fetch-closure
Fetch a store path closure from a binary cache, and return the store path as a string with context.
This function can be invoked in three ways, that we will discuss in order of preference.
Fetch a content-addressed store path
Example:
builtins.fetchClosure { fromStore = "https://cache.nixos.org"; fromPath = /nix/store/ldbhlwhh39wha58rm61bkiiwm6j7211j-git-2.33.1; }
This is the simplest invocation, and it does not require the user of the expression to configure
trusted-public-keys
to ensure their authenticity.If your store path is input addressed instead of content addressed, consider the other two invocations.
Fetch any store path and rewrite it to a fully content-addressed store path
Example:
builtins.fetchClosure { fromStore = "https://cache.nixos.org"; fromPath = /nix/store/r2jd6ygnmirm2g803mksqqjm4y39yi6i-git-2.33.1; toPath = /nix/store/ldbhlwhh39wha58rm61bkiiwm6j7211j-git-2.33.1; }
This example fetches
/nix/store/r2jd...
from the specified binary cache, and rewrites it into the content-addressed store path/nix/store/ldbh...
.Like the previous example, no extra configuration or privileges are required.
To find out the correct value for
toPath
given afromPath
, usenix store make-content-addressed
:# nix store make-content-addressed --from https://cache.nixos.org /nix/store/r2jd6ygnmirm2g803mksqqjm4y39yi6i-git-2.33.1 rewrote '/nix/store/r2jd6ygnmirm2g803mksqqjm4y39yi6i-git-2.33.1' to '/nix/store/ldbhlwhh39wha58rm61bkiiwm6j7211j-git-2.33.1'
Alternatively, set
toPath = ""
and find the correcttoPath
in the error message.Fetch an input-addressed store path as is
Example:
builtins.fetchClosure { fromStore = "https://cache.nixos.org"; fromPath = /nix/store/r2jd6ygnmirm2g803mksqqjm4y39yi6i-git-2.33.1; inputAddressed = true; }
It is possible to fetch an input-addressed store path and return it as is. However, this is the least preferred way of invoking
fetchClosure
, because it requires that the input-addressed paths are trusted by the Nix configuration.builtins.storePath
fetchClosure
is similar tobuiltins.storePath
in that it allows you to use a previously built store path in a Nix expression. However,fetchClosure
is more reproducible because it specifies a binary cache from which the path can be fetched. Also, using content-addressed store paths does not require users to configuretrusted-public-keys
to ensure their authenticity. -
fetchGit args
-
Fetch a path from git. args can be a URL, in which case the HEAD of the repo at that URL is fetched. Otherwise, it can be an attribute with the following attributes (all except
url
optional):-
url
The URL of the repo.
-
name
(default:source
)The name of the directory the repo should be exported to in the store.
-
rev
(default: the tip ofref
)The Git revision to fetch. This is typically a commit hash.
-
ref
(default:HEAD
)The Git reference under which to look for the requested revision. This is often a branch or tag name.
This option has no effect once
shallow
cloning is enabled.By default, the
ref
value is prefixed withrefs/heads/
. As of 2.3.0, Nix will not prefixrefs/heads/
ifref
starts withrefs/
. -
submodules
(default:false
)A Boolean parameter that specifies whether submodules should be checked out.
-
exportIgnore
(default:true
)A Boolean parameter that specifies whether
export-ignore
from.gitattributes
should be applied. This approximates part of thegit archive
behavior.Enabling this option is not recommended because it is unknown whether the Git developers commit to the reproducibility of
export-ignore
in newer Git versions. -
shallow
(default:false
)Make a shallow clone when fetching the Git tree. When this is enabled, the options
ref
andallRefs
have no effect anymore. -
allRefs
Whether to fetch all references (eg. branches and tags) of the repository. With this argument being true, it's possible to load a
rev
from anyref
. (by default onlyrev
s from the specifiedref
are supported).This option has no effect once
shallow
cloning is enabled. -
verifyCommit
(default:true
ifpublicKey
orpublicKeys
are provided, otherwisefalse
)Whether to check
rev
for a signature matchingpublicKey
orpublicKeys
. IfverifyCommit
is enabled, thenfetchGit
cannot use a local repository with uncommitted changes. Requires theverified-fetches
experimental feature. -
publicKey
The public key against which
rev
is verified ifverifyCommit
is enabled. Requires theverified-fetches
experimental feature. -
keytype
(default:"ssh-ed25519"
)The key type of
publicKey
. Possible values:"ssh-dsa"
"ssh-ecdsa"
"ssh-ecdsa-sk"
"ssh-ed25519"
"ssh-ed25519-sk"
"ssh-rsa"
Requires theverified-fetches
experimental feature.
-
publicKeys
The public keys against which
rev
is verified ifverifyCommit
is enabled. Must be given as a list of attribute sets with the following form:{ key = "<public key>"; type = "<key type>"; # optional, default: "ssh-ed25519" }
Requires the
verified-fetches
experimental feature.
Here are some examples of how to use
fetchGit
.-
To fetch a private repository over SSH:
builtins.fetchGit { url = "git@github.com:my-secret/repository.git"; ref = "master"; rev = "adab8b916a45068c044658c4158d81878f9ed1c3"; }
-
To fetch an arbitrary reference:
builtins.fetchGit { url = "https://github.com/NixOS/nix.git"; ref = "refs/heads/0.5-release"; }
-
If the revision you're looking for is in the default branch of the git repository you don't strictly need to specify the branch name in the
ref
attribute.However, if the revision you're looking for is in a future branch for the non-default branch you will need to specify the the
ref
attribute as well.builtins.fetchGit { url = "https://github.com/nixos/nix.git"; rev = "841fcbd04755c7a2865c51c1e2d3b045976b7452"; ref = "1.11-maintenance"; }
Note
It is nice to always specify the branch which a revision belongs to. Without the branch being specified, the fetcher might fail if the default branch changes. Additionally, it can be confusing to try a commit from a non-default branch and see the fetch fail. If the branch is specified the fault is much more obvious.
-
If the revision you're looking for is in the default branch of the git repository you may omit the
ref
attribute.builtins.fetchGit { url = "https://github.com/nixos/nix.git"; rev = "841fcbd04755c7a2865c51c1e2d3b045976b7452"; }
-
To fetch a specific tag:
builtins.fetchGit { url = "https://github.com/nixos/nix.git"; ref = "refs/tags/1.9"; }
-
To fetch the latest version of a remote branch:
builtins.fetchGit { url = "ssh://git@github.com/nixos/nix.git"; ref = "master"; }
-
To verify the commit signature:
builtins.fetchGit { url = "ssh://git@github.com/nixos/nix.git"; verifyCommit = true; publicKeys = [ { type = "ssh-ed25519"; key = "AAAAC3NzaC1lZDI1NTE5AAAAIArPKULJOid8eS6XETwUjO48/HKBWl7FTCK0Z//fplDi"; } ]; }
Nix will refetch the branch according to the
tarball-ttl
setting.This behavior is disabled in pure evaluation mode.
-
To fetch the content of a checked-out work directory:
builtins.fetchGit ./work-dir
If the URL points to a local directory, and no
ref
orrev
is given,fetchGit
will use the current content of the checked-out files, even if they are not committed or added to Git's index. It will only consider files added to the Git repository, as listed bygit ls-files
. -
-
fetchTarball args
-
Download the specified URL, unpack it and return the path of the unpacked tree. The file must be a tape archive (
.tar
) compressed withgzip
,bzip2
orxz
. If the tarball consists of a single directory, then the top-level path component of the files in the tarball is removed. The typical use of the function is to obtain external Nix expression dependencies, such as a particular version of Nixpkgs, e.g.with import (fetchTarball https://github.com/NixOS/nixpkgs/archive/nixos-14.12.tar.gz) {}; stdenv.mkDerivation { … }
The fetched tarball is cached for a certain amount of time (1 hour by default) in
~/.cache/nix/tarballs/
. You can change the cache timeout either on the command line with--tarball-ttl
number-of-seconds or in the Nix configuration file by adding the linetarball-ttl =
number-of-seconds.Note that when obtaining the hash with
nix-prefetch-url
the option--unpack
is required.This function can also verify the contents against a hash. In that case, the function takes a set instead of a URL. The set requires the attribute
url
and the attributesha256
, e.g.with import (fetchTarball { url = "https://github.com/NixOS/nixpkgs/archive/nixos-14.12.tar.gz"; sha256 = "1jppksrfvbk5ypiqdz4cddxdl8z6zyzdb2srq8fcffr327ld5jj2"; }) {}; stdenv.mkDerivation { … }
Not available in restricted evaluation mode.
-
fetchTree input
-
Note
This function is only available if the
fetch-tree
experimental feature is enabled.For example, include the following in
nix.conf
:extra-experimental-features = fetch-tree
Fetch a file system tree or a plain file using one of the supported backends and return an attribute set with:
- the resulting fixed-output store path
- the corresponding NAR hash
- backend-specific metadata (currently not documented).
input must be an attribute set with the following attributes:
-
type
(String, required)One of the supported source types. This determines other required and allowed input attributes.
-
narHash
(String, optional)The
narHash
parameter can be used to substitute the source of the tree. It also allows for verification of tree contents that may not be provided by the underlying transfer mechanism. IfnarHash
is set, the source is first looked up is the Nix store and substituters, and only fetched if not available.
A subset of the output attributes of
fetchTree
can be re-used for subsequent calls tofetchTree
to produce the same result again. That is,fetchTree
is idempotent.Downloads are cached in
$XDG_CACHE_HOME/nix
. The remote source will be fetched from the network if both are true:-
A NAR hash is supplied and the corresponding store path is not valid, that is, not available in the store
Note
Substituters are not used in fetching.
-
There is no cache entry or the cache entry is older than
tarball-ttl
Source types
The following source types and associated input attributes are supported.
-
"file"
Place a plain file into the Nix store. This is similar to
builtins.fetchurl
-
url
(String, required)Supported protocols:
-
https
Example
fetchTree { type = "file"; url = "https://example.com/index.html"; }
-
http
Insecure HTTP transfer for legacy sources.
Warning
HTTP performs no encryption or authentication. Use a
narHash
known in advance to ensure the output has expected contents. -
file
A file on the local file system.
Example
fetchTree { type = "file"; url = "file:///home/eelco/nix/README.md"; }
-
-
-
"tarball"
Download a tar archive and extract it into the Nix store. This has the same underyling implementation as
builtins.fetchTarball
-
url
(String, required)Example
fetchTree { type = "tarball"; url = "https://github.com/NixOS/nixpkgs/tarball/nixpkgs-23.11"; }
-
-
"git"
Fetch a Git tree and copy it to the Nix store. This is similar to
builtins.fetchGit
.-
url
(String, required)The URL formats supported are the same as for Git itself.
Example
fetchTree { type = "git"; url = "git@github.com:NixOS/nixpkgs.git"; }
Note
If the URL points to a local directory, and no
ref
orrev
is given, Nix will only consider files added to the Git index, as listed bygit ls-files
but use the current file contents of the Git working directory. -
ref
(String, optional)By default, this has no effect. This becomes relevant only once
shallow
cloning is disabled.A Git reference, such as a branch or tag name.
Default:
"HEAD"
-
rev
(String, optional)A Git revision; a commit hash.
Default: the tip of
ref
-
shallow
(Bool, optional)Make a shallow clone when fetching the Git tree. When this is enabled, the options
ref
andallRefs
have no effect anymore.Default:
true
-
submodules
(Bool, optional)Also fetch submodules if available.
Default:
false
-
allRefs
(Bool, optional)By default, this has no effect. This becomes relevant only once
shallow
cloning is disabled.Whether to fetch all references (eg. branches and tags) of the repository. With this argument being true, it's possible to load a
rev
from anyref
. (Without setting this option, onlyrev
s from the specifiedref
are supported).Default:
false
-
lastModified
(Integer, optional)Unix timestamp of the fetched commit.
If set, pass through the value to the output attribute set. Otherwise, generated from the fetched Git tree.
-
revCount
(Integer, optional)Number of revisions in the history of the Git repository before the fetched commit.
If set, pass through the value to the output attribute set. Otherwise, generated from the fetched Git tree.
-
The following input types are still subject to change:
"path"
"github"
"gitlab"
"sourcehut"
"mercurial"
input can also be a URL-like reference. The additional input types and the URL-like syntax requires the
flakes
experimental feature to be enabled.Example
Fetch a GitHub repository using the attribute set representation:
builtins.fetchTree { type = "github"; owner = "NixOS"; repo = "nixpkgs"; rev = "ae2e6b3958682513d28f7d633734571fb18285dd"; }
This evaluates to the following attribute set:
{ lastModified = 1686503798; lastModifiedDate = "20230611171638"; narHash = "sha256-rA9RqKP9OlBrgGCPvfd5HVAXDOy8k2SmPtB/ijShNXc="; outPath = "/nix/store/l5m6qlvfs9sdw14ja3qbzpglcjlb6j1x-source"; rev = "ae2e6b3958682513d28f7d633734571fb18285dd"; shortRev = "ae2e6b3"; }
Example
Fetch the same GitHub repository using the URL-like syntax:
builtins.fetchTree "github:NixOS/nixpkgs/ae2e6b3958682513d28f7d633734571fb18285dd"
-
fetchurl arg
-
Download the specified URL and return the path of the downloaded file.
arg
can be either a string denoting the URL, or an attribute set with the following attributes:-
url
The URL of the file to download.
-
name
(default: the last path component of the URL)A name for the file in the store. This can be useful if the URL has any characters that are invalid for the store.
Not available in restricted evaluation mode.
-
-
filter f list
-
Return a list consisting of the elements of list for which the function f returns
true
. -
filterSource e1 e2
-
Warning
filterSource
should not be used to filter store paths. SincefilterSource
uses the name of the input directory while naming the output directory, doing so will produce a directory name in the form of<hash2>-<hash>-<name>
, where<hash>-<name>
is the name of the input directory. Since<hash>
depends on the unfiltered directory, the name of the output directory will indirectly depend on files that are filtered out by the function. This will trigger a rebuild even when a filtered out file is changed. Usebuiltins.path
instead, which allows specifying the name of the output directory.This function allows you to copy sources into the Nix store while filtering certain files. For instance, suppose that you want to use the directory
source-dir
as an input to a Nix expression, e.g.stdenv.mkDerivation { ... src = ./source-dir; }
However, if
source-dir
is a Subversion working copy, then all those annoying.svn
subdirectories will also be copied to the store. Worse, the contents of those directories may change a lot, causing lots of spurious rebuilds. WithfilterSource
you can filter out the.svn
directories:src = builtins.filterSource (path: type: type != "directory" || baseNameOf path != ".svn") ./source-dir;
Thus, the first argument e1 must be a predicate function that is called for each regular file, directory or symlink in the source tree e2. If the function returns
true
, the file is copied to the Nix store, otherwise it is omitted. The function is called with two arguments. The first is the full path of the file. The second is a string that identifies the type of the file, which is either"regular"
,"directory"
,"symlink"
or"unknown"
(for other kinds of files such as device nodes or fifos — but note that those cannot be copied to the Nix store, so if the predicate returnstrue
for them, the copy will fail). If you exclude a directory, the entire corresponding subtree of e2 will be excluded. -
findFile search-path lookup-path
-
Find lookup-path in search-path.
Lookup path expressions are desugared using this and
builtins.nixPath
:<nixpkgs>
is equivalent to:
builtins.findFile builtins.nixPath "nixpkgs"
A search path is represented as a list of attribute sets with two attributes:
prefix
is a relative path.path
denotes a file system location
Examples of search path attribute sets:
-
{ prefix = ""; path = "/nix/var/nix/profiles/per-user/root/channels"; }
-
{ prefix = "nixos-config"; path = "/etc/nixos/configuration.nix"; }
-
{ prefix = "nixpkgs"; path = "https://github.com/NixOS/nixpkgs/tarballs/master"; }
-
{ prefix = "nixpkgs"; path = "channel:nixpkgs-unstable"; }
-
{ prefix = "flake-compat"; path = "flake:github:edolstra/flake-compat"; }
The lookup algorithm checks each entry until a match is found, returning a path value of the match:
-
If a prefix of
lookup-path
matchesprefix
, then the remainder of lookup-path (the "suffix") is searched for within the directory denoted bypath
. The contents ofpath
may need to be downloaded at this point to look inside. -
If the suffix is found inside that directory, then the entry is a match. The combined absolute path of the directory (now downloaded if need be) and the suffix is returned.
Example
A search-path value
[ { prefix = ""; path = "/home/eelco/Dev"; } { prefix = "nixos-config"; path = "/etc/nixos"; } ]
and a lookup-path value
"nixos-config"
will cause Nix to try/home/eelco/Dev/nixos-config
and/etc/nixos
in that order and return the first path that exists.If
path
starts withhttp://
orhttps://
, it is interpreted as the URL of a tarball that will be downloaded and unpacked to a temporary location. The tarball must consist of a single top-level directory.The URLs of the tarballs from the official
nixos.org
channels can be abbreviated aschannel:<channel-name>
. See documentation onnix-channel
for details about channels.Example
These two search path entries are equivalent:
-
{ prefix = "nixpkgs"; path = "channel:nixpkgs-unstable"; }
-
{ prefix = "nixpkgs"; path = "https://nixos.org/channels/nixos-unstable/nixexprs.tar.xz"; }
Search paths can also point to source trees using flake URLs.
Example
The search path entry
{ prefix = "nixpkgs"; path = "flake:nixpkgs"; }
specifies that the prefix
nixpkgs
shall refer to the source tree downloaded from thenixpkgs
entry in the flake registry.Similarly
{ prefix = "nixpkgs"; path = "flake:github:nixos/nixpkgs/nixos-22.05"; }
makes
<nixpkgs>
refer to a particular branch of theNixOS/nixpkgs
repository on GitHub. -
flakeRefToString attrs
-
Note
This function is only available if the
flakes
experimental feature is enabled.For example, include the following in
nix.conf
:extra-experimental-features = flakes
Convert a flake reference from attribute set format to URL format.
For example:
builtins.flakeRefToString { dir = "lib"; owner = "NixOS"; ref = "23.05"; repo = "nixpkgs"; type = "github"; }
evaluates to
"github:NixOS/nixpkgs/23.05?dir=lib"
-
floor double
-
Converts an IEEE-754 double-precision floating-point number (double) to the next lower integer.
If the datatype is neither an integer nor a "float", an evaluation error will be thrown.
-
foldl' op nul list
-
Reduce a list by applying a binary operator, from left to right, e.g.
foldl' op nul [x0 x1 x2 ...] = op (op (op nul x0) x1) x2) ...
.For example,
foldl' (acc: elem: acc + elem) 0 [1 2 3]
evaluates to6
andfoldl' (acc: elem: { "${elem}" = elem; } // acc) {} ["a" "b"]
evaluates to{ a = "a"; b = "b"; }
.The first argument of
op
is the accumulator whereas the second argument is the current element being processed. The return value of each application ofop
is evaluated immediately, even for intermediate values. -
fromJSON e
-
Convert a JSON string to a Nix value. For example,
builtins.fromJSON ''{"x": [1, 2, 3], "y": null}''
returns the value
{ x = [ 1 2 3 ]; y = null; }
. -
fromTOML e
-
Convert a TOML string to a Nix value. For example,
builtins.fromTOML '' x=1 s="a" [table] y=2 ''
returns the value
{ s = "a"; table = { y = 2; }; x = 1; }
. -
functionArgs f
-
Return a set containing the names of the formal arguments expected by the function f. The value of each attribute is a Boolean denoting whether the corresponding argument has a default value. For instance,
functionArgs ({ x, y ? 123}: ...) = { x = false; y = true; }
."Formal argument" here refers to the attributes pattern-matched by the function. Plain lambdas are not included, e.g.
functionArgs (x: ...) = { }
. -
genList generator length
-
Generate list of size length, with each element i equal to the value returned by generator
i
. For example,builtins.genList (x: x * x) 5
returns the list
[ 0 1 4 9 16 ]
. -
genericClosure attrset
-
builtins.genericClosure
iteratively computes the transitive closure over an arbitrary relation defined by a function.It takes attrset with two attributes named
startSet
andoperator
, and returns a list of attribute sets:-
startSet
: The initial list of attribute sets. -
operator
: A function that takes an attribute set and returns a list of attribute sets. It defines how each item in the current set is processed and expanded into more items.
Each attribute set in the list
startSet
and the list returned byoperator
must have an attributekey
, which must support equality comparison. The value ofkey
can be one of the following types:The result is produced by calling the
operator
on eachitem
that has not been called yet, including newly added items, until no new items are added. Items are compared by theirkey
attribute.Common usages are:
- Generating unique collections of items, such as dependency graphs.
- Traversing through structures that may contain cycles or loops.
- Processing data structures with complex internal relationships.
Example
builtins.genericClosure { startSet = [ {key = 5;} ]; operator = item: [{ key = if (item.key / 2 ) * 2 == item.key then item.key / 2 else 3 * item.key + 1; }]; }
evaluates to
[ { key = 5; } { key = 16; } { key = 8; } { key = 4; } { key = 2; } { key = 1; } ]
-
-
getAttr s set
-
getAttr
returns the attribute named s from set. Evaluation aborts if the attribute doesn’t exist. This is a dynamic version of the.
operator, since s is an expression rather than an identifier. -
getContext s
-
Return the string context of s.
The string context tracks references to derivations within a string. It is represented as an attribute set of store derivation paths mapping to output names.
Using string interpolation on a derivation will add that derivation to the string context. For example,
builtins.getContext "${derivation { name = "a"; builder = "b"; system = "c"; }}"
evaluates to
{ "/nix/store/arhvjaf6zmlyn8vh8fgn55rpwnxq0n7l-a.drv" = { outputs = [ "out" ]; }; }
-
getEnv s
-
getEnv
returns the value of the environment variable s, or an empty string if the variable doesn’t exist. This function should be used with care, as it can introduce all sorts of nasty environment dependencies in your Nix expression.getEnv
is used in Nix Packages to locate the file~/.nixpkgs/config.nix
, which contains user-local settings for Nix Packages. (That is, it does agetEnv "HOME"
to locate the user’s home directory.) -
getFlake args
-
Note
This function is only available if the
flakes
experimental feature is enabled.For example, include the following in
nix.conf
:extra-experimental-features = flakes
Fetch a flake from a flake reference, and return its output attributes and some metadata. For example:
(builtins.getFlake "nix/55bc52401966fbffa525c574c14f67b00bc4fb3a").packages.x86_64-linux.nix
Unless impure evaluation is allowed (
--impure
), the flake reference must be "locked", e.g. contain a Git revision or content hash. An example of an unlocked usage is:(builtins.getFlake "github:edolstra/dwarffs").rev
-
groupBy f list
-
Groups elements of list together by the string returned from the function f called on each element. It returns an attribute set where each attribute value contains the elements of list that are mapped to the same corresponding attribute name returned by f.
For example,
builtins.groupBy (builtins.substring 0 1) ["foo" "bar" "baz"]
evaluates to
{ b = [ "bar" "baz" ]; f = [ "foo" ]; }
-
hasAttr s set
-
hasAttr
returnstrue
if set has an attribute named s, andfalse
otherwise. This is a dynamic version of the?
operator, since s is an expression rather than an identifier. -
hasContext s
-
Return
true
if string s has a non-empty context. The context can be obtained withgetContext
.Example
Many operations require a string context to be empty because they are intended only to work with "regular" strings, and also to help users avoid unintentionally loosing track of string context elements.
builtins.hasContext
can help create better domain-specific errors in those case.name: meta: if builtins.hasContext name then throw "package name cannot contain string context" else { ${name} = meta; }
-
hashFile type p
-
Return a base-16 representation of the cryptographic hash of the file at path p. The hash algorithm specified by type must be one of
"md5"
,"sha1"
,"sha256"
or"sha512"
. -
hashString type s
-
Return a base-16 representation of the cryptographic hash of string s. The hash algorithm specified by type must be one of
"md5"
,"sha1"
,"sha256"
or"sha512"
. -
head list
-
Return the first element of a list; abort evaluation if the argument isn’t a list or is an empty list. You can test whether a list is empty by comparing it with
[]
. -
import path
-
Load, parse, and return the Nix expression in the file path.
Note
Unlike some languages,
import
is a regular function in Nix.The path argument must meet the same criteria as an interpolated expression.
If path is a directory, the file
default.nix
in that directory is used if it exists.Example
$ echo 123 > default.nix
Import
default.nix
from the current directory.import ./.
123
Evaluation aborts if the file doesn’t exist or contains an invalid Nix expression.
A Nix expression loaded by
import
must not contain any free variables, that is, identifiers that are not defined in the Nix expression itself and are not built-in. Therefore, it cannot refer to variables that are in scope at the call site.Example
If you have a calling expression
rec { x = 123; y = import ./foo.nix; }
then the following
foo.nix
will give an error:# foo.nix x + 456
since
x
is not in scope infoo.nix
. If you wantx
to be available infoo.nix
, pass it as a function argument:rec { x = 123; y = import ./foo.nix x; }
and
# foo.nix x: x + 456
The function argument doesn’t have to be called
x
infoo.nix
; any name would work. -
intersectAttrs e1 e2
-
Return a set consisting of the attributes in the set e2 which have the same name as some attribute in e1.
Performs in O(n log m) where n is the size of the smaller set and m the larger set's size.
-
isAttrs e
-
Return
true
if e evaluates to a set, andfalse
otherwise. -
isBool e
-
Return
true
if e evaluates to a bool, andfalse
otherwise. -
isFloat e
-
Return
true
if e evaluates to a float, andfalse
otherwise. -
isFunction e
-
Return
true
if e evaluates to a function, andfalse
otherwise. -
isInt e
-
Return
true
if e evaluates to an integer, andfalse
otherwise. -
isList e
-
Return
true
if e evaluates to a list, andfalse
otherwise. -
isNull e
-
Return
true
if e evaluates tonull
, andfalse
otherwise.This is equivalent to
e == null
. -
isPath e
-
Return
true
if e evaluates to a path, andfalse
otherwise. -
isString e
-
Return
true
if e evaluates to a string, andfalse
otherwise. -
langVersion
(integer) -
The current version of the Nix language.
-
length e
-
Return the length of the list e.
-
lessThan e1 e2
-
Return
true
if the number e1 is less than the number e2, andfalse
otherwise. Evaluation aborts if either e1 or e2 does not evaluate to a number. -
listToAttrs e
-
Construct a set from a list specifying the names and values of each attribute. Each element of the list should be a set consisting of a string-valued attribute
name
specifying the name of the attribute, and an attributevalue
specifying its value.In case of duplicate occurrences of the same name, the first takes precedence.
Example:
builtins.listToAttrs [ { name = "foo"; value = 123; } { name = "bar"; value = 456; } { name = "bar"; value = 420; } ]
evaluates to
{ foo = 123; bar = 456; }
-
map f list
-
Apply the function f to each element in the list list. For example,
map (x: "foo" + x) [ "bar" "bla" "abc" ]
evaluates to
[ "foobar" "foobla" "fooabc" ]
. -
mapAttrs f attrset
-
Apply function f to every element of attrset. For example,
builtins.mapAttrs (name: value: value * 10) { a = 1; b = 2; }
evaluates to
{ a = 10; b = 20; }
. -
match regex str
-
Returns a list if the extended POSIX regular expression regex matches str precisely, otherwise returns
null
. Each item in the list is a regex group.builtins.match "ab" "abc"
Evaluates to
null
.builtins.match "abc" "abc"
Evaluates to
[ ]
.builtins.match "a(b)(c)" "abc"
Evaluates to
[ "b" "c" ]
.builtins.match "[[:space:]]+([[:upper:]]+)[[:space:]]+" " FOO "
Evaluates to
[ "FOO" ]
. -
mul e1 e2
-
Return the product of the numbers e1 and e2.
-
nixPath
(list) -
The value of the
nix-path
configuration setting: a list of search path entries used to resolve lookup paths.Example
$ NIX_PATH= nix-instantiate --eval --expr "builtins.nixPath" -I foo=bar --no-pure-eval [ { path = "bar"; prefix = "foo"; } ]
Lookup path expressions are desugared using this and
builtins.findFile
:<nixpkgs>
is equivalent to:
builtins.findFile builtins.nixPath "nixpkgs"
-
nixVersion
(string) -
The version of Nix.
For example, where the command line returns the current Nix version,
$ nix --version nix (Nix) 2.16.0
the Nix language evaluator returns the same value:
nix-repl> builtins.nixVersion "2.16.0"
-
null
(null) -
Primitive value.
The name
null
is not special, and can be shadowed:nix-repl> let null = 1; in null 1
-
outputOf derivation-reference output-name
-
Note
This function is only available if the
dynamic-derivations
experimental feature is enabled.For example, include the following in
nix.conf
:extra-experimental-features = dynamic-derivations
Return the output path of a derivation, literally or using a placeholder if needed.
If the derivation has a statically-known output path (i.e. the derivation output is input-addressed, or fixed content-addresed), the output path will just be returned. But if the derivation is content-addressed or if the derivation is itself not-statically produced (i.e. is the output of another derivation), a placeholder will be returned instead.
derivation reference
must be a string that may contain a regular store path to a derivation, or may be a placeholder reference. If the derivation is produced by a derivation, you must explicitly selectdrv.outPath
. This primop can be chained arbitrarily deeply. For instance,builtins.outputOf (builtins.outputOf myDrv "out") "out"
will return a placeholder for the output of the output of
myDrv
.This primop corresponds to the
^
sigil for derivable paths, e.g. as part of installable syntax on the command line. -
parseDrvName s
-
Split the string s into a package name and version. The package name is everything up to but not including the first dash not followed by a letter, and the version is everything following that dash. The result is returned in a set
{ name, version }
. Thus,builtins.parseDrvName "nix-0.12pre12876"
returns{ name = "nix"; version = "0.12pre12876"; }
. -
parseFlakeRef flake-ref
-
Note
This function is only available if the
flakes
experimental feature is enabled.For example, include the following in
nix.conf
:extra-experimental-features = flakes
Parse a flake reference, and return its exploded form.
For example:
builtins.parseFlakeRef "github:NixOS/nixpkgs/23.05?dir=lib"
evaluates to:
{ dir = "lib"; owner = "NixOS"; ref = "23.05"; repo = "nixpkgs"; type = "github"; }
-
partition pred list
-
Given a predicate function pred, this function returns an attrset containing a list named
right
, containing the elements in list for which pred returnedtrue
, and a list namedwrong
, containing the elements for which it returnedfalse
. For example,builtins.partition (x: x > 10) [1 23 9 3 42]
evaluates to
{ right = [ 23 42 ]; wrong = [ 1 9 3 ]; }
-
path args
-
An enrichment of the built-in path type, based on the attributes present in args. All are optional except
path
:-
path
The underlying path. -
name
The name of the path when added to the store. This can used to reference paths that have nix-illegal characters in their names, like@
. -
filter
A function of the type expected bybuiltins.filterSource
, with the same semantics. -
recursive
Whenfalse
, whenpath
is added to the store it is with a flat hash, rather than a hash of the NAR serialization of the file. Thus,path
must refer to a regular file, not a directory. This allows similar behavior tofetchurl
. Defaults totrue
. -
sha256
When provided, this is the expected hash of the file at the path. Evaluation will fail if the hash is incorrect, and providing a hash allowsbuiltins.path
to be used even when thepure-eval
nix config option is on.
-
-
pathExists path
-
Return
true
if the path path exists at evaluation time, andfalse
otherwise. -
placeholder output
-
Return a placeholder string for the specified output that will be substituted by the corresponding output path at build time. Typical outputs would be
"out"
,"bin"
or"dev"
. -
readDir path
-
Return the contents of the directory path as a set mapping directory entries to the corresponding file type. For instance, if directory
A
contains a regular fileB
and another directoryC
, thenbuiltins.readDir ./A
will return the set{ B = "regular"; C = "directory"; }
The possible values for the file type are
"regular"
,"directory"
,"symlink"
and"unknown"
. -
readFile path
-
Return the contents of the file path as a string.
-
readFileType p
-
Determine the directory entry type of a filesystem node, being one of "directory", "regular", "symlink", or "unknown".
-
removeAttrs set list
-
Remove the attributes listed in list from set. The attributes don’t have to exist in set. For instance,
removeAttrs { x = 1; y = 2; z = 3; } [ "a" "x" "z" ]
evaluates to
{ y = 2; }
. -
replaceStrings from to s
-
Given string s, replace every occurrence of the strings in from with the corresponding string in to.
The argument to is lazy, that is, it is only evaluated when its corresponding pattern in from is matched in the string s
Example:
builtins.replaceStrings ["oo" "a"] ["a" "i"] "foobar"
evaluates to
"fabir"
. -
seq e1 e2
-
Evaluate e1, then evaluate and return e2. This ensures that a computation is strict in the value of e1.
-
sort comparator list
-
Return list in sorted order. It repeatedly calls the function comparator with two elements. The comparator should return
true
if the first element is less than the second, andfalse
otherwise. For example,builtins.sort builtins.lessThan [ 483 249 526 147 42 77 ]
produces the list
[ 42 77 147 249 483 526 ]
.This is a stable sort: it preserves the relative order of elements deemed equal by the comparator.
-
split regex str
-
Returns a list composed of non matched strings interleaved with the lists of the extended POSIX regular expression regex matches of str. Each item in the lists of matched sequences is a regex group.
builtins.split "(a)b" "abc"
Evaluates to
[ "" [ "a" ] "c" ]
.builtins.split "([ac])" "abc"
Evaluates to
[ "" [ "a" ] "b" [ "c" ] "" ]
.builtins.split "(a)|(c)" "abc"
Evaluates to
[ "" [ "a" null ] "b" [ null "c" ] "" ]
.builtins.split "([[:upper:]]+)" " FOO "
Evaluates to
[ " " [ "FOO" ] " " ]
. -
splitVersion s
-
Split a string representing a version into its components, by the same version splitting logic underlying the version comparison in
nix-env -u
. -
storeDir
(string) -
Logical file system location of the Nix store currently in use.
This value is determined by the
store
parameter in Store URLs:$ nix-instantiate --store 'dummy://?store=/blah' --eval --expr builtins.storeDir "/blah"
-
storePath path
-
This function allows you to define a dependency on an already existing store path. For example, the derivation attribute
src = builtins.storePath /nix/store/f1d18v1y…-source
causes the derivation to depend on the specified path, which must exist or be substitutable. Note that this differs from a plain path (e.g.src = /nix/store/f1d18v1y…-source
) in that the latter causes the path to be copied again to the Nix store, resulting in a new path (e.g./nix/store/ld01dnzc…-source-source
).Not available in pure evaluation mode.
See also
builtins.fetchClosure
. -
stringLength e
-
Return the number of bytes of the string e. If e is not a string, evaluation is aborted.
-
sub e1 e2
-
Return the difference between the numbers e1 and e2.
-
substring start len s
-
Return the substring of s from character position start (zero-based) up to but not including start + len. If start is greater than the length of the string, an empty string is returned. If start + len lies beyond the end of the string or len is
-1
, only the substring up to the end of the string is returned. start must be non-negative. For example,builtins.substring 0 3 "nixos"
evaluates to
"nix"
. -
tail list
-
Return the list without its first item; abort evaluation if the argument isn’t a list or is an empty list.
Warning
This function should generally be avoided since it's inefficient: unlike Haskell's
tail
, it takes O(n) time, so recursing over a list by repeatedly callingtail
takes O(n^2) time. -
throw s
-
Throw an error message s. This usually aborts Nix expression evaluation, but in
nix-env -qa
and other commands that try to evaluate a set of derivations to get information about those derivations, a derivation that throws an error is silently skipped (which is not the case forabort
). -
toFile name s
-
Store the string s in a file in the Nix store and return its path. The file has suffix name. This file can be used as an input to derivations. One application is to write builders “inline”. For instance, the following Nix expression combines the Nix expression for GNU Hello and its build script into one file:
{ stdenv, fetchurl, perl }: stdenv.mkDerivation { name = "hello-2.1.1"; builder = builtins.toFile "builder.sh" " source $stdenv/setup PATH=$perl/bin:$PATH tar xvfz $src cd hello-* ./configure --prefix=$out make make install "; src = fetchurl { url = "http://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz"; sha256 = "1md7jsfd8pa45z73bz1kszpp01yw6x5ljkjk2hx7wl800any6465"; }; inherit perl; }
It is even possible for one file to refer to another, e.g.,
builder = let configFile = builtins.toFile "foo.conf" " # This is some dummy configuration file. ... "; in builtins.toFile "builder.sh" " source $stdenv/setup ... cp ${configFile} $out/etc/foo.conf ";
Note that
${configFile}
is a string interpolation, so the result of the expressionconfigFile
(i.e., a path like/nix/store/m7p7jfny445k...-foo.conf
) will be spliced into the resulting string.It is however not allowed to have files mutually referring to each other, like so:
let foo = builtins.toFile "foo" "...${bar}..."; bar = builtins.toFile "bar" "...${foo}..."; in foo
This is not allowed because it would cause a cyclic dependency in the computation of the cryptographic hashes for
foo
andbar
.It is also not possible to reference the result of a derivation. If you are using Nixpkgs, the
writeTextFile
function is able to do that. -
toJSON e
-
Return a string containing a JSON representation of e. Strings, integers, floats, booleans, nulls and lists are mapped to their JSON equivalents. Sets (except derivations) are represented as objects. Derivations are translated to a JSON string containing the derivation’s output path. Paths are copied to the store and represented as a JSON string of the resulting store path.
-
toPath s
-
DEPRECATED. Use
/. + "/path"
to convert a string into an absolute path. For relative paths, use./. + "/path"
. -
toString e
-
Convert the expression e to a string. e can be:
-
A string (in which case the string is returned unmodified).
-
A path (e.g.,
toString /foo/bar
yields"/foo/bar"
. -
A set containing
{ __toString = self: ...; }
or{ outPath = ...; }
. -
An integer.
-
A list, in which case the string representations of its elements are joined with spaces.
-
A Boolean (
false
yields""
,true
yields"1"
). -
null
, which yields the empty string.
-
-
toXML e
-
Return a string containing an XML representation of e. The main application for
toXML
is to communicate information with the builder in a more structured format than plain environment variables.Here is an example where this is the case:
{ stdenv, fetchurl, libxslt, jira, uberwiki }: stdenv.mkDerivation (rec { name = "web-server"; buildInputs = [ libxslt ]; builder = builtins.toFile "builder.sh" " source $stdenv/setup mkdir $out echo "$servlets" | xsltproc ${stylesheet} - > $out/server-conf.xml ① "; stylesheet = builtins.toFile "stylesheet.xsl" ② "<?xml version='1.0' encoding='UTF-8'?> <xsl:stylesheet xmlns:xsl='http://www.w3.org/1999/XSL/Transform' version='1.0'> <xsl:template match='/'> <Configure> <xsl:for-each select='/expr/list/attrs'> <Call name='addWebApplication'> <Arg><xsl:value-of select=\"attr[@name = 'path']/string/@value\" /></Arg> <Arg><xsl:value-of select=\"attr[@name = 'war']/path/@value\" /></Arg> </Call> </xsl:for-each> </Configure> </xsl:template> </xsl:stylesheet> "; servlets = builtins.toXML [ ③ { path = "/bugtracker"; war = jira + "/lib/atlassian-jira.war"; } { path = "/wiki"; war = uberwiki + "/uberwiki.war"; } ]; })
The builder is supposed to generate the configuration file for a Jetty servlet container. A servlet container contains a number of servlets (
*.war
files) each exported under a specific URI prefix. So the servlet configuration is a list of sets containing thepath
andwar
of the servlet (①). This kind of information is difficult to communicate with the normal method of passing information through an environment variable, which just concatenates everything together into a string (which might just work in this case, but wouldn’t work if fields are optional or contain lists themselves). Instead the Nix expression is converted to an XML representation withtoXML
, which is unambiguous and can easily be processed with the appropriate tools. For instance, in the example an XSLT stylesheet (at point ②) is applied to it (at point ①) to generate the XML configuration file for the Jetty server. The XML representation produced at point ③ bytoXML
is as follows:<?xml version='1.0' encoding='utf-8'?> <expr> <list> <attrs> <attr name="path"> <string value="/bugtracker" /> </attr> <attr name="war"> <path value="/nix/store/d1jh9pasa7k2...-jira/lib/atlassian-jira.war" /> </attr> </attrs> <attrs> <attr name="path"> <string value="/wiki" /> </attr> <attr name="war"> <path value="/nix/store/y6423b1yi4sx...-uberwiki/uberwiki.war" /> </attr> </attrs> </list> </expr>
Note that we used the
toFile
built-in to write the builder and the stylesheet “inline” in the Nix expression. The path of the stylesheet is spliced into the builder using the syntaxxsltproc ${stylesheet}
. -
trace e1 e2
-
Evaluate e1 and print its abstract syntax representation on standard error. Then return e2. This function is useful for debugging.
If the
debugger-on-trace
option is set totrue
and the--debugger
flag is given, the interactive debugger will be started whentrace
is called (likebreak
). -
traceVerbose e1 e2
-
Evaluate e1 and print its abstract syntax representation on standard error if
--trace-verbose
is enabled. Then return e2. This function is useful for debugging. -
true
(Boolean) -
Primitive value.
It can be returned by comparison operators and used in conditional expressions.
The name
true
is not special, and can be shadowed:nix-repl> let true = 1; in true 1
-
tryEval e
-
Try to shallowly evaluate e. Return a set containing the attributes
success
(true
if e evaluated successfully,false
if an error was thrown) andvalue
, equalling e if successful andfalse
otherwise.tryEval
will only prevent errors created bythrow
orassert
from being thrown. ErrorstryEval
will not catch are for example those created byabort
and type errors generated by builtins. Also note that this doesn't evaluate e deeply, solet e = { x = throw ""; }; in (builtins.tryEval e).success
will betrue
. Usingbuiltins.deepSeq
one can get the expected result:let e = { x = throw ""; }; in (builtins.tryEval (builtins.deepSeq e e)).success
will befalse
. -
typeOf e
-
Return a string representing the type of the value e, namely
"int"
,"bool"
,"string"
,"path"
,"null"
,"set"
,"list"
,"lambda"
or"float"
. -
unsafeDiscardOutputDependency s
-
Create a copy of the given string where every derivation deep string context element is turned into a constant string context element.
This is the opposite of
builtins.addDrvOutputDependencies
.This is unsafe because it allows us to "forget" store objects we would have otherwise refered to with the string context, whereas Nix normally tracks all dependencies consistently. Safe operations "grow" but never "shrink" string contexts.
builtins.addDrvOutputDependencies
in contrast is safe because "derivation deep" string context element always refers to the underlying derivation (among many more things). Replacing a constant string context element with a "derivation deep" element is a safe operation that just enlargens the string context without forgetting anything. -
unsafeDiscardStringContext s
-
Discard the string context from a value that can be coerced to a string.
-
warn e1 e2
-
Evaluate e1, which must be a string and print iton standard error as a warning. Then return e2. This function is useful for non-critical situations where attention is advisable.
If the
debugger-on-trace
ordebugger-on-warn
option is set totrue
and the--debugger
flag is given, the interactive debugger will be started whenwarn
is called (likebreak
).If the
abort-on-warn
option is set, the evaluation will be aborted after the warning is printed. This is useful to reveal the stack trace of the warning, when the context is non-interactive and a debugger can not be launched. -
zipAttrsWith f list
-
Transpose a list of attribute sets into an attribute set of lists, then apply
mapAttrs
.f
receives two arguments: the attribute name and a non-empty list of all values encountered for that attribute name.The result is an attribute set where the attribute names are the union of the attribute names in each element of
list
. The attribute values are the return values off
.builtins.zipAttrsWith (name: values: { inherit name values; }) [ { a = "x"; } { a = "y"; b = "z"; } ]
evaluates to
{ a = { name = "a"; values = [ "x" "y" ]; }; b = { name = "b"; values = [ "z" ]; }; }
Derivations
The most important built-in function is derivation
, which is used to describe a single derivation:
a specification for running an executable on precisely defined input files to repeatably produce output files at uniquely determined file system paths.
It takes as input an attribute set, the attributes of which specify the inputs to the process. It outputs an attribute set, and produces a store derivation as a side effect of evaluation.
Input attributes
Required
-
A symbolic name for the derivation. It is added to the store path of the corresponding store derivation as well as to its output paths.
Example
derivation { name = "hello"; # ... }
The store derivation's path will be
/nix/store/<hash>-hello.drv
. The output paths will be of the form/nix/store/<hash>-hello[-<output>]
-
The system type on which the
builder
executable is meant to be run.A necessary condition for Nix to build derivations locally is that the
system
attribute matches the currentsystem
configuration option. It can automatically build on other platforms by forwarding build requests to other machines.Example
Declare a derivation to be built on a specific system type:
derivation { # ... system = "x86_64-linux"; # ... }
Example
Declare a derivation to be built on the system type that evaluates the expression:
derivation { # ... system = builtins.currentSystem; # ... }
builtins.currentSystem
has the value of thesystem
configuration option, and defaults to the system type of the current Nix installation. -
Path to an executable that will perform the build.
Example
Use the file located at
/bin/bash
as the builder executable:derivation { # ... builder = "/bin/bash"; # ... };
Example
Copy a local file to the Nix store for use as the builder executable:
derivation { # ... builder = ./builder.sh; # ... };
Example
Use a file from another derivation as the builder executable:
let pkgs = import <nixpkgs> {}; in derivation { # ... builder = "${pkgs.python}/bin/python"; # ... };
Optional
-
Default:
[ ]
Command-line arguments to be passed to the
builder
executable.Example
Pass arguments to Bash to interpret a shell command:
derivation { # ... builder = "/bin/bash"; args = [ "-c" "echo hello world > $out" ]; # ... };
-
Default:
[ "out" ]
Symbolic outputs of the derivation. Each output name is passed to the
builder
executable as an environment variable with its value set to the corresponding store path.By default, a derivation produces a single output called
out
. However, derivations can produce multiple outputs. This allows the associated store objects and their closures to be copied or garbage-collected separately.Example
Imagine a library package that provides a dynamic library, header files, and documentation. A program that links against such a library doesn’t need the header files and documentation at runtime, and it doesn’t need the documentation at build time. Thus, the library package could specify:
derivation { # ... outputs = [ "lib" "dev" "doc" ]; # ... }
This will cause Nix to pass environment variables
lib
,dev
, anddoc
to the builder containing the intended store paths of each output. The builder would typically do something like./configure \ --libdir=$lib/lib \ --includedir=$dev/include \ --docdir=$doc/share/doc
for an Autoconf-style package.
The name of an output is combined with the name of the derivation to create the name part of the output's store path, unless it is
out
, in which case just the name of the derivation is used.Example
derivation { name = "example"; outputs = [ "lib" "dev" "doc" "out" ]; # ... }
The store derivation path will be
/nix/store/<hash>-example.drv
. The output paths will be/nix/store/<hash>-example-lib
/nix/store/<hash>-example-dev
/nix/store/<hash>-example-doc
/nix/store/<hash>-example
You can refer to each output of a derivation by selecting it as an attribute. The first element of
outputs
determines the default output and ends up at the top-level.Example
Select an output by attribute name:
let myPackage = derivation { name = "example"; outputs = [ "lib" "dev" "doc" "out" ]; # ... }; in myPackage.dev
Since
lib
is the first output,myPackage
is equivalent tomyPackage.lib
. -
See Advanced Attributes for more, infrequently used, optional attributes.
-
Every other attribute is passed as an environment variable to the builder. Attribute values are translated to environment variables as follows:
-
Strings are passed unchanged.
-
Integral numbers are converted to decimal notation.
-
Floating point numbers are converted to simple decimal or scientific notation with a preset precision.
-
A path (e.g.,
../foo/sources.tar
) causes the referenced file to be copied to the store; its location in the store is put in the environment variable. The idea is that all sources should reside in the Nix store, since all inputs to a derivation should reside in the Nix store. -
A derivation causes that derivation to be built prior to the present derivation. The environment variable is set to the store path of the derivation's default output.
-
Lists of the previous types are also allowed. They are simply concatenated, separated by spaces.
-
true
is passed as the string1
,false
andnull
are passed as an empty string.
-
Builder execution
The builder
is executed as follows:
-
A temporary directory is created under the directory specified by
TMPDIR
(default/tmp
) where the build will take place. The current directory is changed to this directory. -
The environment is cleared and set to the derivation attributes, as specified above.
-
In addition, the following variables are set:
-
NIX_BUILD_TOP
contains the path of the temporary directory for this build. -
Also,
TMPDIR
,TEMPDIR
,TMP
,TEMP
are set to point to the temporary directory. This is to prevent the builder from accidentally writing temporary files anywhere else. Doing so might cause interference by other processes. -
PATH
is set to/path-not-set
to prevent shells from initialising it to their built-in default value. -
HOME
is set to/homeless-shelter
to prevent programs from using/etc/passwd
or the like to find the user's home directory, which could cause impurity. Usually, whenHOME
is set, it is used as the location of the home directory, even if it points to a non-existent path. -
NIX_STORE
is set to the path of the top-level Nix store directory (typically,/nix/store
). -
NIX_ATTRS_JSON_FILE
&NIX_ATTRS_SH_FILE
if__structuredAttrs
is set totrue
for the derivation. A detailed explanation of this behavior can be found in the section about structured attrs. -
For each output declared in
outputs
, the corresponding environment variable is set to point to the intended path in the Nix store for that output. Each output path is a concatenation of the cryptographic hash of all build inputs, thename
attribute and the output name. (The output name is omitted if it’sout
.)
-
-
If an output path already exists, it is removed. Also, locks are acquired to prevent multiple Nix instances from performing the same build at the same time.
-
A log of the combined standard output and error is written to
/nix/var/log/nix
. -
The builder is executed with the arguments specified by the attribute
args
. If it exits with exit code 0, it is considered to have succeeded. -
The temporary directory is removed (unless the
-K
option was specified). -
If the build was successful, Nix scans each output path for references to input paths by looking for the hash parts of the input paths. Since these are potential runtime dependencies, Nix registers them as dependencies of the output paths.
-
After the build, Nix sets the last-modified timestamp on all files in the build result to 1 (00:00:01 1/1/1970 UTC), sets the group to the default group, and sets the mode of the file to 0444 or 0555 (i.e., read-only, with execute permission enabled if the file was originally executable). Note that possible
setuid
andsetgid
bits are cleared. Setuid and setgid programs are not currently supported by Nix. This is because the Nix archives used in deployment have no concept of ownership information, and because it makes the build result dependent on the user performing the build.
Advanced Attributes
Derivations can declare some infrequently used optional attributes.
-
allowedReferences
The optional attributeallowedReferences
specifies a list of legal references (dependencies) of the output of the builder. For example,allowedReferences = [];
enforces that the output of a derivation cannot have any runtime dependencies on its inputs. To allow an output to have a runtime dependency on itself, use
"out"
as a list item. This is used in NixOS to check that generated files such as initial ramdisks for booting Linux don’t have accidental dependencies on other paths in the Nix store. -
allowedRequisites
This attribute is similar toallowedReferences
, but it specifies the legal requisites of the whole closure, so all the dependencies recursively. For example,allowedRequisites = [ foobar ];
enforces that the output of a derivation cannot have any other runtime dependency than
foobar
, and in addition it enforces thatfoobar
itself doesn't introduce any other dependency itself. -
disallowedReferences
The optional attributedisallowedReferences
specifies a list of illegal references (dependencies) of the output of the builder. For example,disallowedReferences = [ foo ];
enforces that the output of a derivation cannot have a direct runtime dependencies on the derivation
foo
. -
disallowedRequisites
This attribute is similar todisallowedReferences
, but it specifies illegal requisites for the whole closure, so all the dependencies recursively. For example,disallowedRequisites = [ foobar ];
enforces that the output of a derivation cannot have any runtime dependency on
foobar
or any other derivation depending recursively onfoobar
. -
exportReferencesGraph
This attribute allows builders access to the references graph of their inputs. The attribute is a list of inputs in the Nix store whose references graph the builder needs to know. The value of this attribute should be a list of pairs[ name1 path1 name2 path2 ... ]
. The references graph of each pathN will be stored in a text file nameN in the temporary build directory. The text files have the format used bynix-store --register-validity
(with the deriver fields left empty). For example, when the following derivation is built:derivation { ... exportReferencesGraph = [ "libfoo-graph" libfoo ]; };
the references graph of
libfoo
is placed in the filelibfoo-graph
in the temporary build directory.exportReferencesGraph
is useful for builders that want to do something with the closure of a store path. Examples include the builders in NixOS that generate the initial ramdisk for booting Linux (acpio
archive containing the closure of the boot script) and the ISO-9660 image for the installation CD (which is populated with a Nix store containing the closure of a bootable NixOS configuration). -
impureEnvVars
This attribute allows you to specify a list of environment variables that should be passed from the environment of the calling user to the builder. Usually, the environment is cleared completely when the builder is executed, but with this attribute you can allow specific environment variables to be passed unmodified. For example,fetchurl
in Nixpkgs has the lineimpureEnvVars = [ "http_proxy" "https_proxy" ... ];
to make it use the proxy server configuration specified by the user in the environment variables
http_proxy
and friends.This attribute is only allowed in fixed-output derivations (see below), where impurities such as these are okay since (the hash of) the output is known in advance. It is ignored for all other derivations.
Warning
impureEnvVars
implementation takes environment variables from the current builder process. When a daemon is building its environmental variables are used. Without the daemon, the environmental variables come from the environment of thenix-build
.If the
configurable-impure-env
experimental feature is enabled, these environment variables can also be controlled through theimpure-env
configuration setting. -
outputHash
;outputHashAlgo
;outputHashMode
These attributes declare that the derivation is a so-called fixed-output derivation (FOD), which means that a cryptographic hash of the output is already known in advance.As opposed to regular derivations, the
builder
executable of a fixed-output derivation has access to the network. Nix computes a cryptographic hash of its output and compares that to the hash declared with these attributes. If there is a mismatch, the derivation fails.The rationale for fixed-output derivations is derivations such as those produced by the
fetchurl
function. This function downloads a file from a given URL. To ensure that the downloaded file has not been modified, the caller must also specify a cryptographic hash of the file. For example,fetchurl { url = "http://ftp.gnu.org/pub/gnu/hello/hello-2.1.1.tar.gz"; sha256 = "1md7jsfd8pa45z73bz1kszpp01yw6x5ljkjk2hx7wl800any6465"; }
It sometimes happens that the URL of the file changes, e.g., because servers are reorganised or no longer available. We then must update the call to
fetchurl
, e.g.,fetchurl { url = "ftp://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz"; sha256 = "1md7jsfd8pa45z73bz1kszpp01yw6x5ljkjk2hx7wl800any6465"; }
If a
fetchurl
derivation was treated like a normal derivation, the output paths of the derivation and all derivations depending on it would change. For instance, if we were to change the URL of the Glibc source distribution in Nixpkgs (a package on which almost all other packages depend) massive rebuilds would be needed. This is unfortunate for a change which we know cannot have a real effect as it propagates upwards through the dependency graph.For fixed-output derivations, on the other hand, the name of the output path only depends on the
outputHash*
andname
attributes, while all other attributes are ignored for the purpose of computing the output path. (Thename
attribute is included because it is part of the path.)As an example, here is the (simplified) Nix expression for
fetchurl
:{ stdenv, curl }: # The curl program is used for downloading. { url, sha256 }: stdenv.mkDerivation { name = baseNameOf (toString url); builder = ./builder.sh; buildInputs = [ curl ]; # This is a fixed-output derivation; the output must be a regular # file with SHA256 hash sha256. outputHashMode = "flat"; outputHashAlgo = "sha256"; outputHash = sha256; inherit url; }
The
outputHash
attribute must be a string containing the hash in either hexadecimal or "nix32" encoding, or following the format for integrity metadata as defined by SRI. The "nix32" encoding is an adaptation of base-32 encoding. TheconvertHash
function shows how to convert between different encodings, and thenix-hash
command has information about obtaining the hash for some contents, as well as converting to and from encodings.The
outputHashAlgo
attribute specifies the hash algorithm used to compute the hash. It can currently be"sha1"
,"sha256"
,"sha512"
, ornull
.outputHashAlgo
can only benull
whenoutputHash
follows the SRI format.The
outputHashMode
attribute determines how the hash is computed. It must be one of the following values:-
This is the default.
-
Compatibility
"recursive"
is the traditional way of indicating this, and is supported since 2005 (virtually the entire history of Nix)."nar"
is more clear, and consistent with other parts of Nix (such as the CLI), however support for it is only added in Nix version 2.21. -
Warning
The use of this method for derivation outputs is part of the
dynamic-derivations
experimental feature. -
Warning
This method is part of the
git-hashing
experimental feature.
-
-
Warning This attribute is part of an experimental feature.
To use this attribute, you must enable the
ca-derivations
experimental feature. For example, in nix.conf you could add:extra-experimental-features = ca-derivations
If this attribute is set to
true
, then the derivation outputs will be stored in a content-addressed location rather than the traditional input-addressed one.Setting this attribute also requires setting
outputHashMode
andoutputHashAlgo
like for fixed-output derivations (see above).It also implicitly requires that the machine to build the derivation must have the
ca-derivations
system feature. -
passAsFile
A list of names of attributes that should be passed via files rather than environment variables. For example, if you havepassAsFile = ["big"]; big = "a very long string";
then when the builder runs, the environment variable
bigPath
will contain the absolute path to a temporary file containinga very long string
. That is, for any attribute x listed inpassAsFile
, Nix will pass an environment variablexPath
holding the path of the file containing the value of attribute x. This is useful when you need to pass large strings to a builder, since most operating systems impose a limit on the size of the environment (typically, a few hundred kilobyte). -
preferLocalBuild
If this attribute is set totrue
and distributed building is enabled, then, if possible, the derivation will be built locally instead of being forwarded to a remote machine. This is useful for derivations that are cheapest to build locally. -
allowSubstitutes
If this attribute is set tofalse
, then Nix will always build this derivation (locally or remotely); it will not try to substitute its outputs. This is useful for derivations that are cheaper to build than to substitute.This attribute can be ignored by setting
always-allow-substitutes
totrue
.Note
If set to
false
, thebuilder
should be able to run on the system type specified in thesystem
attribute, since the derivation cannot be substituted. -
__structuredAttrs
If the special attribute__structuredAttrs
is set totrue
, the other derivation attributes are serialised into a file in JSON format. The environment variableNIX_ATTRS_JSON_FILE
points to the exact location of that file both in a build and anix-shell
. This obviates the need forpassAsFile
since JSON files have no size restrictions, unlike process environments.It also makes it possible to tweak derivation settings in a structured way; see
outputChecks
for example.As a convenience to Bash builders, Nix writes a script that initialises shell variables corresponding to all attributes that are representable in Bash. The environment variable
NIX_ATTRS_SH_FILE
points to the exact location of the script, both in a build and anix-shell
. This includes non-nested (associative) arrays. For example, the attributehardening.format = true
ends up as the Bash associative array element${hardening[format]}
.Warning
If set to
true
, other advanced attributes such asallowedReferences
,allowedReferences
,allowedRequisites
,disallowedReferences
anddisallowedRequisites
, maxSize, and maxClosureSize. will have no effect. -
outputChecks
When using structured attributes, theoutputChecks
attribute allows defining checks per-output.In addition to
allowedReferences
,allowedRequisites
,disallowedReferences
anddisallowedRequisites
, the following attributes are available:maxSize
defines the maximum size of the resulting store object.maxClosureSize
defines the maximum size of the output's closure.ignoreSelfRefs
controls whether self-references should be considered when checking for allowed references/requisites.
Example:
__structuredAttrs = true; outputChecks.out = { # The closure of 'out' must not be larger than 256 MiB. maxClosureSize = 256 * 1024 * 1024; # It must not refer to the C compiler or to the 'dev' output. disallowedRequisites = [ stdenv.cc "dev" ]; }; outputChecks.dev = { # The 'dev' output must not be larger than 128 KiB. maxSize = 128 * 1024; };
-
When using structured attributes, the attribute
unsafeDiscardReferences
is an attribute set with a boolean value for each output name. If set totrue
, it disables scanning the output for runtime dependencies.Example:
__structuredAttrs = true; unsafeDiscardReferences.out = true;
This is useful, for example, when generating self-contained filesystem images with their own embedded Nix store: hashes found inside such an image refer to the embedded store and not to the host's Nix store.
-
If a derivation has the
requiredSystemFeatures
attribute, then Nix will only build it on a machine that has the corresponding features set in itssystem-features
configuration.For example, setting
requiredSystemFeatures = [ "kvm" ];
ensures that the derivation can only be built on a machine with the
kvm
feature.
Import From Derivation
The value of a Nix expression can depend on the contents of a store object.
Passing an expression expr
that evaluates to a store path to any built-in function which reads from the filesystem constitutes Import From Derivation (IFD):
import
expr
builtins.readFile
expr
builtins.readFileType
expr
builtins.readDir
expr
builtins.pathExists
expr
builtins.filterSource
f expr
builtins.path
{ path = expr; }
builtins.hashFile
t expr
builtins.scopedImport x drv
When the store path needs to be accessed, evaluation will be paused, the corresponding store object realised, and then evaluation resumed.
This has performance implications: Evaluation can only finish when all required store objects are realised. Since the Nix language evaluator is sequential, it only finds store paths to read from one at a time. While realisation is always parallel, in this case it cannot be done for all required store paths at once, and is therefore much slower than otherwise.
Realising store objects during evaluation can be disabled by setting allow-import-from-derivation
to false
.
Without IFD it is ensured that evaluation is complete and Nix can produce a build plan before starting any realisation.
Example
In the following Nix expression, the inner derivation drv
produces a file with contents hello
.
# IFD.nix
let
drv = derivation {
name = "hello";
builder = "/bin/sh";
args = [ "-c" "echo -n hello > $out" ];
system = builtins.currentSystem;
};
in "${builtins.readFile drv} world"
nix-instantiate IFD.nix --eval --read-write-mode
building '/nix/store/348q1cal6sdgfxs8zqi9v8llrsn4kqkq-hello.drv'...
"hello world"
The contents of the derivation's output have to be realised before they can be read with readFile
.
Only then evaluation can continue to produce the final result.
Illustration
As a first approximation, the following data flow graph shows how evaluation and building are interleaved, if the value of a Nix expression depends on realising a store object. Boxes are data structures, arrow labels are transformations.
+----------------------+ +------------------------+
| Nix evaluator | | Nix store |
| .----------------. | | |
| | Nix expression | | | |
| '----------------' | | |
| | | | |
| evaluate | | |
| | | | |
| V | | |
| .------------. | | .------------------. |
| | derivation |----|-instantiate-|->| store derivation | |
| '------------' | | '------------------' |
| | | | |
| | | realise |
| | | | |
| | | V |
| .----------------. | | .--------------. |
| | Nix expression |<-|----read-----|----| store object | |
| '----------------' | | '--------------' |
| | | | |
| evaluate | | |
| | | | |
| V | | |
| .------------. | | |
| | value | | | |
| '------------' | | |
+----------------------+ +------------------------+
In more detail, the following sequence diagram shows how the expression is evaluated step by step, and where evaluation is blocked to wait for the build output to appear.
.-------. .-------------. .---------.
|Nix CLI| |Nix evaluator| |Nix store|
'-------' '-------------' '---------'
| | |
|evaluate IFD.nix| |
|--------------->| |
| | |
| evaluate `"${readFile drv} world"` |
| | |
| evaluate `readFile drv` |
| | |
| evaluate `drv` as string |
| | |
| |instantiate /nix/store/...-hello.drv|
| |----------------------------------->|
| : |
| : realise /nix/store/...-hello.drv |
| :----------------------------------->|
| : |
| |--------.
| : | |
| (evaluation blocked) | echo hello > $out
| : | |
| |<-------'
| : /nix/store/...-hello |
| |<-----------------------------------|
| | |
| resume `readFile /nix/store/...-hello` |
| | |
| | readFile /nix/store/...-hello |
| |----------------------------------->|
| | |
| | hello |
| |<-----------------------------------|
| | |
| resume `"${"hello"} world"` |
| | |
| resume `"hello world"` |
| | |
| "hello world" | |
|<---------------| |
.-------. .-------------. .---------.
|Nix CLI| |Nix evaluator| |Nix store|
'-------' '-------------' '---------'
This chapter discusses how to do package management with Nix, i.e., how to obtain, install, upgrade, and erase packages. This is the “user’s” perspective of the Nix system — people who want to create packages should consult the chapter on the Nix language.
Profiles
Profiles and user environments are Nix’s mechanism for implementing the
ability to allow different users to have different configurations, and
to do atomic upgrades and rollbacks. To understand how they work, it’s
useful to know a bit about how Nix works. In Nix, packages are stored in
unique locations in the Nix store (typically, /nix/store
). For
instance, a particular version of the Subversion package might be stored
in a directory
/nix/store/dpmvp969yhdqs7lm2r1a3gng7pyq6vy4-subversion-1.1.3/
, while
another version might be stored in
/nix/store/5mq2jcn36ldlmh93yj1n8s9c95pj7c5s-subversion-1.1.2
. The long
strings prefixed to the directory names are cryptographic hashes (to be
precise, 160-bit truncations of SHA-256 hashes encoded in a base-32
notation) of all inputs involved in building the package — sources,
dependencies, compiler flags, and so on. So if two packages differ in
any way, they end up in different locations in the file system, so they
don’t interfere with each other. Here is what a part of a typical Nix
store looks like:
Of course, you wouldn’t want to type
$ /nix/store/dpmvp969yhdq...-subversion-1.1.3/bin/svn
every time you want to run Subversion. Of course we could set up the
PATH
environment variable to include the bin
directory of every
package we want to use, but this is not very convenient since changing
PATH
doesn’t take effect for already existing processes. The solution
Nix uses is to create directory trees of symlinks to activated
packages. These are called user environments and they are packages
themselves (though automatically generated by nix-env
), so they too
reside in the Nix store. For instance, in the figure above, the user
environment /nix/store/0c1p5z4kda11...-user-env
contains a symlink to
just Subversion 1.1.2 (arrows in the figure indicate symlinks). This
would be what we would obtain if we had done
$ nix-env --install --attr nixpkgs.subversion
on a set of Nix expressions that contained Subversion 1.1.2.
This doesn’t in itself solve the problem, of course; you wouldn’t want
to type /nix/store/0c1p5z4kda11...-user-env/bin/svn
either. That’s why
there are symlinks outside of the store that point to the user
environments in the store; for instance, the symlinks default-42-link
and default-43-link
in the example. These are called generations
since every time you perform a nix-env
operation, a new user
environment is generated based on the current one. For instance,
generation 43 was created from generation 42 when we did
$ nix-env --install --attr nixpkgs.subversion nixpkgs.firefox
on a set of Nix expressions that contained Firefox and a new version of Subversion.
Generations are grouped together into profiles so that different users don’t interfere with each other if they don’t want to. For example:
$ ls -l /nix/var/nix/profiles/
...
lrwxrwxrwx 1 eelco ... default-42-link -> /nix/store/0c1p5z4kda11...-user-env
lrwxrwxrwx 1 eelco ... default-43-link -> /nix/store/3aw2pdyx2jfc...-user-env
lrwxrwxrwx 1 eelco ... default -> default-43-link
This shows a profile called default
. The file default
itself is
actually a symlink that points to the current generation. When we do a
nix-env
operation, a new user environment and generation link are
created based on the current one, and finally the default
symlink is
made to point at the new generation. This last step is atomic on Unix,
which explains how we can do atomic upgrades. (Note that the
building/installing of new packages doesn’t interfere in any way with
old packages, since they are stored in different locations in the Nix
store.)
If you find that you want to undo a nix-env
operation, you can just do
$ nix-env --rollback
which will just make the current generation link point at the previous
link. E.g., default
would be made to point at default-42-link
. You
can also switch to a specific generation:
$ nix-env --switch-generation 43
which in this example would roll forward to generation 43 again. You can also see all available generations:
$ nix-env --list-generations
You generally wouldn’t have /nix/var/nix/profiles/some-profile/bin
in
your PATH
. Rather, there is a symlink ~/.nix-profile
that points to
your current profile. This means that you should put
~/.nix-profile/bin
in your PATH
(and indeed, that’s what the
initialisation script /nix/etc/profile.d/nix.sh
does). This makes it
easier to switch to a different profile. You can do that using the
command nix-env --switch-profile
:
$ nix-env --switch-profile /nix/var/nix/profiles/my-profile
$ nix-env --switch-profile /nix/var/nix/profiles/default
These commands switch to the my-profile
and default profile,
respectively. If the profile doesn’t exist, it will be created
automatically. You should be careful about storing a profile in another
location than the profiles
directory, since otherwise it might not be
used as a root of the garbage collector.
All nix-env
operations work on the profile pointed to by
~/.nix-profile
, but you can override this using the --profile
option
(abbreviation -p
):
$ nix-env --profile /nix/var/nix/profiles/other-profile --install --attr nixpkgs.subversion
This will not change the ~/.nix-profile
symlink.
Garbage Collection
nix-env
operations such as upgrades (-u
) and uninstall (-e
) never
actually delete packages from the system. All they do (as shown above)
is to create a new user environment that no longer contains symlinks to
the “deleted” packages.
Of course, since disk space is not infinite, unused packages should be removed at some point. You can do this by running the Nix garbage collector. It will remove from the Nix store any package not used (directly or indirectly) by any generation of any profile.
Note however that as long as old generations reference a package, it will not be deleted. After all, we wouldn’t be able to do a rollback otherwise. So in order for garbage collection to be effective, you should also delete (some) old generations. Of course, this should only be done if you are certain that you will not need to roll back.
To delete all old (non-current) generations of your current profile:
$ nix-env --delete-generations old
Instead of old
you can also specify a list of generations, e.g.,
$ nix-env --delete-generations 10 11 14
To delete all generations older than a specified number of days (except
the current generation), use the d
suffix. For example,
$ nix-env --delete-generations 14d
deletes all generations older than two weeks.
After removing appropriate old generations you can run the garbage collector as follows:
$ nix-store --gc
The behaviour of the garbage collector is affected by the
keep-derivations
(default: true) and keep-outputs
(default: false)
options in the Nix configuration file. The defaults will ensure that all
derivations that are build-time dependencies of garbage collector roots
will be kept and that all output paths that are runtime dependencies
will be kept as well. All other derivations or paths will be collected.
(This is usually what you want, but while you are developing it may make
sense to keep outputs to ensure that rebuild times are quick.) If you
are feeling uncertain, you can also first view what files would be
deleted:
$ nix-store --gc --print-dead
Likewise, the option --print-live
will show the paths that won’t be
deleted.
There is also a convenient little utility nix-collect-garbage
, which
when invoked with the -d
(--delete-old
) switch deletes all old
generations of all profiles in /nix/var/nix/profiles
. So
$ nix-collect-garbage -d
is a quick and easy way to clean up your system.
Garbage Collector Roots
The roots of the garbage collector are all store paths to which there
are symlinks in the directory prefix/nix/var/nix/gcroots
. For
instance, the following command makes the path
/nix/store/d718ef...-foo
a root of the collector:
$ ln -s /nix/store/d718ef...-foo /nix/var/nix/gcroots/bar
That is, after this command, the garbage collector will not remove
/nix/store/d718ef...-foo
or any of its dependencies.
Subdirectories of prefix/nix/var/nix/gcroots
are also searched for
symlinks. Symlinks to non-store paths are followed and searched for
roots, but symlinks to non-store paths inside the paths reached in
that way are not followed to prevent infinite recursion.
This section lists advanced topics related to builds and builds performance
Sharing Packages Between Machines
Sometimes you want to copy a package from one machine to another. Or, you want to install some packages and you know that another machine already has some or all of those packages or their dependencies. In that case there are mechanisms to quickly copy packages between machines.
Serving a Nix store via HTTP
You can easily share the Nix store of a machine via HTTP. This allows other machines to fetch store paths from that machine to speed up installations. It uses the same binary cache mechanism that Nix usually uses to fetch pre-built binaries from https://cache.nixos.org.
The daemon that handles binary cache requests via HTTP, nix-serve
, is
not part of the Nix distribution, but you can install it from Nixpkgs:
$ nix-env --install --attr nixpkgs.nix-serve
You can then start the server, listening for HTTP connections on whatever port you like:
$ nix-serve -p 8080
To check whether it works, try the following on the client:
$ curl http://avalon:8080/nix-cache-info
which should print something like:
StoreDir: /nix/store
WantMassQuery: 1
Priority: 30
On the client side, you can tell Nix to use your binary cache using
--substituters
, e.g.:
$ nix-env --install --attr nixpkgs.firefox --substituters http://avalon:8080/
The option substituters
tells Nix to use this binary cache in
addition to your default caches, such as https://cache.nixos.org.
Thus, for any path in the closure of Firefox, Nix will first check if
the path is available on the server avalon
or another binary caches.
If not, it will fall back to building from source.
You can also tell Nix to always use your binary cache by adding a line
to the nix.conf
configuration file like this:
substituters = http://avalon:8080/ https://cache.nixos.org/
Serving a Nix store via SSH
You can tell Nix to automatically fetch needed binaries from a remote
Nix store via SSH. For example, the following installs Firefox,
automatically fetching any store paths in Firefox’s closure if they are
available on the server avalon
:
$ nix-env --install --attr nixpkgs.firefox --substituters ssh://alice@avalon
This works similar to the binary cache substituter that Nix usually
uses, only using SSH instead of HTTP: if a store path P
is needed, Nix
will first check if it’s available in the Nix store on avalon
. If not,
it will fall back to using the binary cache substituter, and then to
building from source.
Note
The SSH substituter currently does not allow you to enter an SSH passphrase interactively. Therefore, you should use
ssh-add
to load the decrypted private key intossh-agent
.
You can also copy the closure of some store path, without installing it into your profile, e.g.
$ nix-store --realise /nix/store/m85bxg…-firefox-34.0.5 --substituters
ssh://alice@avalon
This is essentially equivalent to doing
$ nix-copy-closure --from alice@avalon
/nix/store/m85bxg…-firefox-34.0.5
You can use SSH’s forced command feature to set up a restricted user
account for SSH substituter access, allowing read-only access to the
local Nix store, but nothing more. For example, add the following lines
to sshd_config
to restrict the user nix-ssh
:
Match User nix-ssh
AllowAgentForwarding no
AllowTcpForwarding no
PermitTTY no
PermitTunnel no
X11Forwarding no
ForceCommand nix-store --serve
Match All
On NixOS, you can accomplish the same by adding the following to your
configuration.nix
:
nix.sshServe.enable = true;
nix.sshServe.keys = [ "ssh-dss AAAAB3NzaC1k... bob@example.org" ];
where the latter line lists the public keys of users that are allowed to connect.
Remote Builds
Nix supports remote builds, where a local Nix installation can forward
Nix builds to other machines. This allows multiple builds to be
performed in parallel and allows Nix to perform multi-platform builds in
a semi-transparent way. For instance, if you perform a build for a
x86_64-darwin
on an i686-linux
machine, Nix can automatically
forward the build to a x86_64-darwin
machine, if available.
To forward a build to a remote machine, it’s required that the remote machine is accessible via SSH and that it has Nix installed. You can test whether connecting to the remote Nix instance works, e.g.
$ nix store ping --store ssh://mac
will try to connect to the machine named mac
. It is possible to
specify an SSH identity file as part of the remote store URI, e.g.
$ nix store ping --store ssh://mac?ssh-key=/home/alice/my-key
Since builds should be non-interactive, the key should not have a
passphrase. Alternatively, you can load identities ahead of time into
ssh-agent
or gpg-agent
.
If you get the error
bash: nix-store: command not found
error: cannot connect to 'mac'
then you need to ensure that the PATH
of non-interactive login shells
contains Nix.
The list of remote build machines can be specified on the command line or in the Nix configuration file.
For example, the following command allows you to build a derivation for x86_64-darwin
on a Linux machine:
$ uname
Linux
$ nix build --impure \
--expr '(with import <nixpkgs> { system = "x86_64-darwin"; }; runCommand "foo" {} "uname > $out")' \
--builders 'ssh://mac x86_64-darwin'
[1/0/1 built, 0.0 MiB DL] building foo on ssh://mac
$ cat ./result
Darwin
It is possible to specify multiple build machines separated by a semicolon or a newline, e.g.
--builders 'ssh://mac x86_64-darwin ; ssh://beastie x86_64-freebsd'
Remote build machines can also be configured in nix.conf
, e.g.
builders = ssh://mac x86_64-darwin ; ssh://beastie x86_64-freebsd
Finally, remote build machines can be configured in a separate configuration
file included in builders
via the syntax @/path/to/file
. For example,
builders = @/etc/nix/machines
causes the list of machines in /etc/nix/machines
to be included.
(This is the default.)
Tuning Cores and Jobs
Nix has two relevant settings with regards to how your CPU cores will
be utilized: cores
and max-jobs
. This chapter will talk about what
they are, how they interact, and their configuration trade-offs.
-
max-jobs
Dictates how many separate derivations will be built at the same time. If you set this to zero, the local machine will do no builds. Nix will still substitute from binary caches, and build remotely if remote builders are configured. -
cores
Suggests how many cores each derivation should use. Similar tomake -j
.
The cores
setting determines the value of
NIX_BUILD_CORES
. NIX_BUILD_CORES
is equal to cores
, unless
cores
equals 0
, in which case NIX_BUILD_CORES
will be the total
number of cores in the system.
The maximum number of consumed cores is a simple multiplication,
max-jobs
* NIX_BUILD_CORES
.
The balance on how to set these two independent variables depends upon each builder's workload and hardware. Here are a few example scenarios on a machine with 24 cores:
max-jobs | cores | NIX_BUILD_CORES | Maximum Processes | Result |
---|---|---|---|---|
1 | 24 | 24 | 24 | One derivation will be built at a time, each one can use 24 cores. Undersold if a job can’t use 24 cores. |
4 | 6 | 6 | 24 | Four derivations will be built at once, each given access to six cores. |
12 | 6 | 6 | 72 | 12 derivations will be built at once, each given access to six cores. This configuration is over-sold. If all 12 derivations being built simultaneously try to use all six cores, the machine's performance will be degraded due to extensive context switching between the 12 builds. |
24 | 1 | 1 | 24 | 24 derivations can build at the same time, each using a single core. Never oversold, but derivations which require many cores will be very slow to compile. |
24 | 0 | 24 | 576 | 24 derivations can build at the same time, each using all the available cores of the machine. Very likely to be oversold, and very likely to suffer context switches. |
It is up to the derivations' build script to respect host's requested
cores-per-build by following the value of the NIX_BUILD_CORES
environment variable.
Verifying Build Reproducibility
You can use Nix's diff-hook
setting to compare build results. Note
that this hook is only executed if the results differ; it is not used
for determining if the results are the same.
For purposes of demonstration, we'll use the following Nix file,
deterministic.nix
for testing:
let
inherit (import <nixpkgs> {}) runCommand;
in {
stable = runCommand "stable" {} ''
touch $out
'';
unstable = runCommand "unstable" {} ''
echo $RANDOM > $out
'';
}
Additionally, nix.conf
contains:
diff-hook = /etc/nix/my-diff-hook
run-diff-hook = true
where /etc/nix/my-diff-hook
is an executable file containing:
#!/bin/sh
exec >&2
echo "For derivation $3:"
/run/current-system/sw/bin/diff -r "$1" "$2"
The diff hook is executed by the same user and group who ran the build. However, the diff hook does not have write access to the store path just built.
Spot-Checking Build Determinism
Verify a path which already exists in the Nix store by passing --check
to the build command.
If the build passes and is deterministic, Nix will exit with a status code of 0:
$ nix-build ./deterministic.nix --attr stable
this derivation will be built:
/nix/store/z98fasz2jqy9gs0xbvdj939p27jwda38-stable.drv
building '/nix/store/z98fasz2jqy9gs0xbvdj939p27jwda38-stable.drv'...
/nix/store/yyxlzw3vqaas7wfp04g0b1xg51f2czgq-stable
$ nix-build ./deterministic.nix --attr stable --check
checking outputs of '/nix/store/z98fasz2jqy9gs0xbvdj939p27jwda38-stable.drv'...
/nix/store/yyxlzw3vqaas7wfp04g0b1xg51f2czgq-stable
If the build is not deterministic, Nix will exit with a status code of 1:
$ nix-build ./deterministic.nix --attr unstable
this derivation will be built:
/nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv
building '/nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv'...
/nix/store/krpqk0l9ib0ibi1d2w52z293zw455cap-unstable
$ nix-build ./deterministic.nix --attr unstable --check
checking outputs of '/nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv'...
error: derivation '/nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv' may
not be deterministic: output '/nix/store/krpqk0l9ib0ibi1d2w52z293zw455cap-unstable' differs
In the Nix daemon's log, we will now see:
For derivation /nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv:
1c1
< 8108
---
> 30204
Using --check
with --keep-failed
will cause Nix to keep the second
build's output in a special, .check
path:
$ nix-build ./deterministic.nix --attr unstable --check --keep-failed
checking outputs of '/nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv'...
note: keeping build directory '/tmp/nix-build-unstable.drv-0'
error: derivation '/nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv' may
not be deterministic: output '/nix/store/krpqk0l9ib0ibi1d2w52z293zw455cap-unstable' differs
from '/nix/store/krpqk0l9ib0ibi1d2w52z293zw455cap-unstable.check'
In particular, notice the
/nix/store/krpqk0l9ib0ibi1d2w52z293zw455cap-unstable.check
output. Nix
has copied the build results to that directory where you can examine it.
Check paths are not protected against garbage collection, and this path will be deleted on the next garbage collection.
The path is guaranteed to be alive for the duration of the
diff-hook
's execution, but may be deleted any time after.If the comparison is performed as part of automated tooling, please use the diff-hook or author your tooling to handle the case where the build was not deterministic and also a check path does not exist.
--check
is only usable if the derivation has been built on the system
already. If the derivation has not been built Nix will fail with the
error:
error: some outputs of '/nix/store/hzi1h60z2qf0nb85iwnpvrai3j2w7rr6-unstable.drv'
are not valid, so checking is not possible
Run the build without --check
, and then try with --check
again.
Using the post-build-hook
Implementation Caveats
Here we use the post-build hook to upload to a binary cache. This is a simple and working example, but it is not suitable for all use cases.
The post build hook program runs after each executed build, and blocks the build loop. The build loop exits if the hook program fails.
Concretely, this implementation will make Nix slow or unusable when the internet is slow or unreliable.
A more advanced implementation might pass the store paths to a user-supplied daemon or queue for processing the store paths outside of the build loop.
Prerequisites
This tutorial assumes you have configured an S3-compatible binary cache as a substituter,
and that the root
user's default AWS profile can upload to the bucket.
Set up a Signing Key
Use nix-store --generate-binary-cache-key
to create our public and
private signing keys. We will sign paths with the private key, and
distribute the public key for verifying the authenticity of the paths.
# nix-store --generate-binary-cache-key example-nix-cache-1 /etc/nix/key.private /etc/nix/key.public
# cat /etc/nix/key.public
example-nix-cache-1:1/cKDz3QCCOmwcztD2eV6Coggp6rqc9DGjWv7C0G+rM=
Then update nix.conf
on any machine that will access the cache.
Add the cache URL to substituters
and the public key to trusted-public-keys
:
substituters = https://cache.nixos.org/ s3://example-nix-cache
trusted-public-keys = cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY= example-nix-cache-1:1/cKDz3QCCOmwcztD2eV6Coggp6rqc9DGjWv7C0G+rM=
Machines that build for the cache must sign derivations using the private key.
On those machines, add the path to the key file to the secret-key-files
field in their nix.conf
:
secret-key-files = /etc/nix/key.private
We will restart the Nix daemon in a later step.
Implementing the build hook
Write the following script to /etc/nix/upload-to-cache.sh
:
#!/bin/sh
set -eu
set -f # disable globbing
export IFS=' '
echo "Uploading paths" $OUT_PATHS
exec nix copy --to "s3://example-nix-cache" $OUT_PATHS
Note
The
$OUT_PATHS
variable is a space-separated list of Nix store paths. In this case, we expect and want the shell to perform word splitting to make each output path its own argument tonix store sign
. Nix guarantees the paths will not contain any spaces, however a store path might contain glob characters. Theset -f
disables globbing in the shell. If you want to upload the.drv
file too, the$DRV_PATH
variable is also defined for the script and works just like$OUT_PATHS
.
Then make sure the hook program is executable by the root
user:
# chmod +x /etc/nix/upload-to-cache.sh
Updating Nix Configuration
Edit /etc/nix/nix.conf
to run our hook, by adding the following
configuration snippet at the end:
post-build-hook = /etc/nix/upload-to-cache.sh
Then, restart the nix-daemon
.
Testing
Build any derivation, for example:
$ nix-build --expr '(import <nixpkgs> {}).writeText "example" (builtins.toString builtins.currentTime)'
this derivation will be built:
/nix/store/s4pnfbkalzy5qz57qs6yybna8wylkig6-example.drv
building '/nix/store/s4pnfbkalzy5qz57qs6yybna8wylkig6-example.drv'...
running post-build-hook '/home/grahamc/projects/github.com/NixOS/nix/post-hook.sh'...
post-build-hook: Signing paths /nix/store/ibcyipq5gf91838ldx40mjsp0b8w9n18-example
post-build-hook: Uploading paths /nix/store/ibcyipq5gf91838ldx40mjsp0b8w9n18-example
/nix/store/ibcyipq5gf91838ldx40mjsp0b8w9n18-example
Then delete the path from the store, and try substituting it from the binary cache:
$ rm ./result
$ nix-store --delete /nix/store/ibcyipq5gf91838ldx40mjsp0b8w9n18-example
Now, copy the path back from the cache:
$ nix-store --realise /nix/store/ibcyipq5gf91838ldx40mjsp0b8w9n18-example
copying path '/nix/store/m8bmqwrch6l3h8s0k3d673xpmipcdpsa-example from 's3://example-nix-cache'...
warning: you did not specify '--add-root'; the result might be removed by the garbage collector
/nix/store/m8bmqwrch6l3h8s0k3d673xpmipcdpsa-example
Conclusion
We now have a Nix installation configured to automatically sign and upload every local build to a remote binary cache.
Before deploying this to production, be sure to consider the implementation caveats.
This section lists commands and options that you can use when you work with Nix.
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Main Commands
This section lists commands and options that you can use when you work with Nix.
Name
nix-build
- build a Nix expression
Synopsis
nix-build
[paths…]
[--arg
name value]
[--argstr
name value]
[{--attr
| -A
} attrPath]
[--no-out-link
]
[--dry-run
]
[{--out-link
| -o
} outlink]
Disambiguation
This man page describes the command nix-build
, which is distinct from nix build
. For documentation on the latter, run nix build --help
or see man nix3-build
.
Description
The nix-build
command builds the derivations described by the Nix
expressions in paths. If the build succeeds, it places a symlink to
the result in the current directory. The symlink is called result
. If
there are multiple Nix expressions, or the Nix expressions evaluate to
multiple derivations, multiple sequentially numbered symlinks are
created (result
, result-2
, and so on).
If no paths are specified, then nix-build
will use default.nix
in
the current directory, if it exists.
If an element of paths starts with http://
or https://
, it is
interpreted as the URL of a tarball that will be downloaded and unpacked
to a temporary location. The tarball must include a single top-level
directory containing at least a file named default.nix
.
nix-build
is essentially a wrapper around
nix-instantiate
(to translate a high-level Nix
expression to a low-level store derivation) and nix-store --realise
(to build the store
derivation).
Warning
The result of the build is automatically registered as a root of the Nix garbage collector. This root disappears automatically when the
result
symlink is deleted or renamed. So don’t rename the symlink.
Options
All options not listed here are passed to
nix-store --realise
,
except for --arg
and --attr
/ -A
which are passed to nix-instantiate
.
-
Do not create a symlink to the output path. Note that as a result the output does not become a root of the garbage collector, and so might be deleted by
nix-store --gc
. -
Show what store paths would be built or downloaded.
-
--out-link
/-o
outlinkChange the name of the symlink to the output path created from
result
to outlink.
Special exit codes for build failure
1xx status codes are used when requested builds failed. The following codes are in use:
-
100
Generic build failureThe builder process returned with a non-zero exit code.
-
101
Build timeoutThe build was aborted because it did not complete within the specified
timeout
. -
102
Hash mismatchThe build output was rejected because it does not match the
outputHash
attribute of the derivation. -
104
Not deterministicThe build succeeded in check mode but the resulting output is not binary reproducible.
With the --keep-going
flag it's possible for multiple failures to occur.
In this case the 1xx status codes are or combined using
bitwise OR.
0b1100100
^^^^
|||`- timeout
||`-- output hash mismatch
|`--- build failure
`---- not deterministic
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Examples
$ nix-build '<nixpkgs>' --attr firefox
store derivation is /nix/store/qybprl8sz2lc...-firefox-1.5.0.7.drv
/nix/store/d18hyl92g30l...-firefox-1.5.0.7
$ ls -l result
lrwxrwxrwx ... result -> /nix/store/d18hyl92g30l...-firefox-1.5.0.7
$ ls ./result/bin/
firefox firefox-config
If a derivation has multiple outputs, nix-build
will build the default
(first) output. You can also build all outputs:
$ nix-build '<nixpkgs>' --attr openssl.all
This will create a symlink for each output named result-outputname
.
The suffix is omitted if the output name is out
. So if openssl
has
outputs out
, bin
and man
, nix-build
will create symlinks
result
, result-bin
and result-man
. It’s also possible to build a
specific output:
$ nix-build '<nixpkgs>' --attr openssl.man
This will create a symlink result-man
.
Build a Nix expression given on the command line:
$ nix-build --expr 'with import <nixpkgs> { }; runCommand "foo" { } "echo bar > $out"'
$ cat ./result
bar
Build the GNU Hello package from the latest revision of the master branch of Nixpkgs:
$ nix-build https://github.com/NixOS/nixpkgs/archive/master.tar.gz --attr hello
Name
nix-shell
- start an interactive shell based on a Nix expression
Synopsis
nix-shell
[--arg
name value]
[--argstr
name value]
[{--attr
| -A
} attrPath]
[--command
cmd]
[--run
cmd]
[--exclude
regexp]
[--pure
]
[--keep
name]
{{--packages
| -p
} {packages | expressions} … | [path]}
Disambiguation
This man page describes the command nix-shell
, which is distinct from nix shell
. For documentation on the latter, run nix shell --help
or see man nix3-shell
.
Description
The command nix-shell
will build the dependencies of the specified
derivation, but not the derivation itself. It will then start an
interactive shell in which all environment variables defined by the
derivation path have been set to their corresponding values, and the
script $stdenv/setup
has been sourced. This is useful for reproducing
the environment of a derivation for development.
If path is not given, nix-shell
defaults to shell.nix
if it
exists, and default.nix
otherwise.
If path starts with http://
or https://
, it is interpreted as the
URL of a tarball that will be downloaded and unpacked to a temporary
location. The tarball must include a single top-level directory
containing at least a file named default.nix
.
If the derivation defines the variable shellHook
, it will be run
after $stdenv/setup
has been sourced. Since this hook is not executed
by regular Nix builds, it allows you to perform initialisation specific
to nix-shell
. For example, the derivation attribute
shellHook =
''
echo "Hello shell"
export SOME_API_TOKEN="$(cat ~/.config/some-app/api-token)"
'';
will cause nix-shell
to print Hello shell
and set the SOME_API_TOKEN
environment variable to a user-configured value.
Options
All options not listed here are passed to nix-store --realise
, except for --arg
and --attr
/ -A
which are passed to
nix-instantiate
.
-
--command
cmdIn the environment of the derivation, run the shell command cmd. This command is executed in an interactive shell. (Use
--run
to use a non-interactive shell instead.) However, a call toexit
is implicitly added to the command, so the shell will exit after running the command. To prevent this, addreturn
at the end; e.g.--command "echo Hello; return"
will printHello
and then drop you into the interactive shell. This can be useful for doing any additional initialisation. -
--run
cmdLike
--command
, but executes the command in a non-interactive shell. This means (among other things) that if you hit Ctrl-C while the command is running, the shell exits. -
--exclude
regexpDo not build any dependencies whose store path matches the regular expression regexp. This option may be specified multiple times.
-
--pure
If this flag is specified, the environment is almost entirely cleared before the interactive shell is started, so you get an environment that more closely corresponds to the “real” Nix build. A few variables, in particular
HOME
,USER
andDISPLAY
, are retained. -
--packages
/-p
packages…Set up an environment in which the specified packages are present. The command line arguments are interpreted as attribute names inside the Nix Packages collection. Thus,
nix-shell --packages libjpeg openjdk
will start a shell in which the packages denoted by the attribute nameslibjpeg
andopenjdk
are present. -
-i
interpreterThe chained script interpreter to be invoked by
nix-shell
. Only applicable in#!
-scripts (described below). -
--keep
nameWhen a
--pure
shell is started, keep the listed environment variables.
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Environment variables
-
NIX_BUILD_SHELL
Shell used to start the interactive environment. Defaults to the
bash
found in<nixpkgs>
, falling back to thebash
found inPATH
if not found.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Examples
To build the dependencies of the package Pan, and start an interactive shell in which to build it:
$ nix-shell '<nixpkgs>' --attr pan
[nix-shell]$ eval ${unpackPhase:-unpackPhase}
[nix-shell]$ cd $sourceRoot
[nix-shell]$ eval ${patchPhase:-patchPhase}
[nix-shell]$ eval ${configurePhase:-configurePhase}
[nix-shell]$ eval ${buildPhase:-buildPhase}
[nix-shell]$ ./pan/gui/pan
The reason we use form eval ${configurePhase:-configurePhase}
here is because
those packages that override these phases do so by exporting the overridden
values in the environment variable of the same name.
Here bash is being told to either evaluate the contents of 'configurePhase',
if it exists as a variable, otherwise evaluate the configurePhase function.
To clear the environment first, and do some additional automatic initialisation of the interactive shell:
$ nix-shell '<nixpkgs>' --attr pan --pure \
--command 'export NIX_DEBUG=1; export NIX_CORES=8; return'
Nix expressions can also be given on the command line using the -E
and
-p
flags. For instance, the following starts a shell containing the
packages sqlite
and libX11
:
$ nix-shell --expr 'with import <nixpkgs> { }; runCommand "dummy" { buildInputs = [ sqlite xorg.libX11 ]; } ""'
A shorter way to do the same is:
$ nix-shell --packages sqlite xorg.libX11
[nix-shell]$ echo $NIX_LDFLAGS
… -L/nix/store/j1zg5v…-sqlite-3.8.0.2/lib -L/nix/store/0gmcz9…-libX11-1.6.1/lib …
Note that -p
accepts multiple full nix expressions that are valid in
the buildInputs = [ ... ]
shown above, not only package names. So the
following is also legal:
$ nix-shell --packages sqlite 'git.override { withManual = false; }'
The -p
flag looks up Nixpkgs in the Nix search path. You can override
it by passing -I
or setting NIX_PATH
. For example, the following
gives you a shell containing the Pan package from a specific revision of
Nixpkgs:
$ nix-shell --packages pan -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/8a3eea054838b55aca962c3fbde9c83c102b8bf2.tar.gz
[nix-shell:~]$ pan --version
Pan 0.139
Use as a #!
-interpreter
You can use nix-shell
as a script interpreter to allow scripts written
in arbitrary languages to obtain their own dependencies via Nix. This is
done by starting the script with the following lines:
#! /usr/bin/env nix-shell
#! nix-shell -i real-interpreter --packages packages
where real-interpreter is the “real” script interpreter that will be
invoked by nix-shell
after it has obtained the dependencies and
initialised the environment, and packages are the attribute names of
the dependencies in Nixpkgs.
The lines starting with #! nix-shell
specify nix-shell
options (see
above). Note that you cannot write #! /usr/bin/env nix-shell -i ...
because many operating systems only allow one argument in #!
lines.
For example, here is a Python script that depends on Python and the
prettytable
package:
#! /usr/bin/env nix-shell
#! nix-shell -i python3 --packages python3 python3Packages.prettytable
import prettytable
# Print a simple table.
t = prettytable.PrettyTable(["N", "N^2"])
for n in range(1, 10): t.add_row([n, n * n])
print(t)
Similarly, the following is a Perl script that specifies that it
requires Perl and the HTML::TokeParser::Simple
and LWP
packages:
#! /usr/bin/env nix-shell
#! nix-shell -i perl --packages perl perlPackages.HTMLTokeParserSimple perlPackages.LWP
use HTML::TokeParser::Simple;
# Fetch nixos.org and print all hrefs.
my $p = HTML::TokeParser::Simple->new(url => 'http://nixos.org/');
while (my $token = $p->get_tag("a")) {
my $href = $token->get_attr("href");
print "$href\n" if $href;
}
Sometimes you need to pass a simple Nix expression to customize a package like Terraform:
#! /usr/bin/env nix-shell
#! nix-shell -i bash --packages 'terraform.withPlugins (plugins: [ plugins.openstack ])'
terraform apply
Note
You must use single or double quotes (
'
,"
) when passing a simple Nix expression in a nix-shell shebang.
Finally, using the merging of multiple nix-shell shebangs the following Haskell script uses a specific branch of Nixpkgs/NixOS (the 20.03 stable branch):
#! /usr/bin/env nix-shell
#! nix-shell -i runghc --packages 'haskellPackages.ghcWithPackages (ps: [ps.download-curl ps.tagsoup])'
#! nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/nixos-20.03.tar.gz
import Network.Curl.Download
import Text.HTML.TagSoup
import Data.Either
import Data.ByteString.Char8 (unpack)
-- Fetch nixos.org and print all hrefs.
main = do
resp <- openURI "https://nixos.org/"
let tags = filter (isTagOpenName "a") $ parseTags $ unpack $ fromRight undefined resp
let tags' = map (fromAttrib "href") tags
mapM_ putStrLn $ filter (/= "") tags'
If you want to be even more precise, you can specify a specific revision of Nixpkgs:
#! nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/0672315759b3e15e2121365f067c1c8c56bb4722.tar.gz
The examples above all used -p
to get dependencies from Nixpkgs. You
can also use a Nix expression to build your own dependencies. For
example, the Python example could have been written as:
#! /usr/bin/env nix-shell
#! nix-shell deps.nix -i python
where the file deps.nix
in the same directory as the #!
-script
contains:
with import <nixpkgs> {};
runCommand "dummy" { buildInputs = [ python pythonPackages.prettytable ]; } ""
The script's file name is passed as the first argument to the interpreter specified by the -i
flag.
Aside from the very first line, which is a directive to the operating system, the additional #! nix-shell
lines do not need to be at the beginning of the file.
This allows wrapping them in block comments for languages where #
does not start a comment, such as ECMAScript, Erlang, PHP, or Ruby.
Name
nix-store
- manipulate or query the Nix store
Synopsis
nix-store
operation [options…] [arguments…]
[--option
name value]
[--add-root
path]
Description
The command nix-store
performs primitive operations on the Nix store.
You generally do not need to run this command manually.
nix-store
takes exactly one operation flag which indicates the subcommand to be performed. The following operations are available:
--realise
--serve
--gc
--delete
--query
--add
--add-fixed
--verify
--verify-path
--repair-path
--dump
--restore
--export
--import
--optimise
--read-log
--dump-db
--load-db
--print-env
--generate-binary-cache-key
These pages can be viewed offline:
-
man nix-store-<operation>
.Example:
man nix-store-realise
-
nix-store --help --<operation>
Example:
nix-store --help --realise
Name
nix-store --add-fixed
- add paths to store using given hashing algorithm
Synopsis
nix-store
--add-fixed
[--recursive
] algorithm paths…
Description
The operation --add-fixed
adds the specified paths to the Nix store.
Unlike --add
paths are registered using the specified hashing
algorithm, resulting in the same output path as a fixed-output
derivation. This can be used for sources that are not available from a
public url or broke since the download expression was written.
This operation has the following options:
-
--recursive
Use recursive instead of flat hashing mode, used when adding directories to the store.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Example
$ nix-store --add-fixed sha256 ./hello-2.10.tar.gz
/nix/store/3x7dwzq014bblazs7kq20p9hyzz0qh8g-hello-2.10.tar.gz
Name
nix-store --add
- add paths to Nix store
Synopsis
nix-store
--add
paths…
Description
The operation --add
adds the specified paths to the Nix store. It
prints the resulting paths in the Nix store on standard output.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Example
$ nix-store --add ./foo.c
/nix/store/m7lrha58ph6rcnv109yzx1nk1cj7k7zf-foo.c
Name
nix-store --delete
- delete store paths
Synopsis
nix-store
--delete
[--ignore-liveness
] paths…
Description
The operation --delete
deletes the store paths paths from the Nix
store, but only if it is safe to do so; that is, when the path is not
reachable from a root of the garbage collector. This means that you can
only delete paths that would also be deleted by nix-store --gc
. Thus,
--delete
is a more targeted version of --gc
.
With the option --ignore-liveness
, reachability from the roots is
ignored. However, the path still won’t be deleted if there are other
paths in the store that refer to it (i.e., depend on it).
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Example
$ nix-store --delete /nix/store/zq0h41l75vlb4z45kzgjjmsjxvcv1qk7-mesa-6.4
0 bytes freed (0.00 MiB)
error: cannot delete path `/nix/store/zq0h41l75vlb4z45kzgjjmsjxvcv1qk7-mesa-6.4' since it is still alive
Name
nix-store --dump-db
- export Nix database
Synopsis
nix-store
--dump-db
[paths…]
Description
The operation --dump-db
writes a dump of the Nix database to standard
output. It can be loaded into an empty Nix store using --load-db
. This
is useful for making backups and when migrating to different database
schemas.
By default, --dump-db
will dump the entire Nix database. When one or
more store paths is passed, only the subset of the Nix database for
those store paths is dumped. As with --export
, the user is responsible
for passing all the store paths for a closure. See --export
for an
example.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Name
nix-store --dump
- write a single path to a Nix Archive
Synopsis
nix-store
--dump
path
Description
The operation --dump
produces a Nix archive (NAR) file containing the
contents of the file system tree rooted at path. The archive is
written to standard output.
A NAR archive is like a TAR or Zip archive, but it contains only the information that Nix considers important. For instance, timestamps are elided because all files in the Nix store have their timestamp set to 0 anyway. Likewise, all permissions are left out except for the execute bit, because all files in the Nix store have 444 or 555 permission.
Also, a NAR archive is canonical, meaning that “equal” paths always
produce the same NAR archive. For instance, directory entries are
always sorted so that the actual on-disk order doesn’t influence the
result. This means that the cryptographic hash of a NAR dump of a
path is usable as a fingerprint of the contents of the path. Indeed,
the hashes of store paths stored in Nix’s database (see nix-store --query --hash
) are SHA-256 hashes of the NAR dump of each store path.
NAR archives support filenames of unlimited length and 64-bit file sizes. They can contain regular files, directories, and symbolic links, but not other types of files (such as device nodes).
A Nix archive can be unpacked using nix-store --restore
.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Name
nix-store --export
- export store paths to a Nix Archive
Synopsis
nix-store
--export
paths…
Description
The operation --export
writes a serialisation of the given store objects to standard output in a format that can be imported into another Nix store with nix-store --import
.
Warning
This command does not produce a closure of the specified store paths. Trying to import a store object that refers to store paths not available in the target Nix store will fail.
Use
nix-store --query
to obtain the closure of a store path.
This command is different from nix-store --dump
, which produces a Nix archive that does not contain the set of references of a given store path.
Note
For efficient transfer of closures to remote machines over SSH, use
nix-copy-closure
.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Examples
Example
Deploy GNU Hello to an airgapped machine via USB stick.
Write the closure to the block device on a machine with internet connection:
[alice@itchy]$ storePath=$(nix-build '<nixpkgs>' -I nixpkgs=channel:nixpkgs-unstable -A hello --no-out-link) [alice@itchy]$ nix-store --export $(nix-store --query --requisites $storePath) | sudo dd of=/dev/usb
Read the closure from the block device on the machine without internet connection:
[bob@scratchy]$ hello=$(sudo dd if=/dev/usb | nix-store --import | tail -1) [bob@scratchy]$ $hello/bin/hello Hello, world!
Name
nix-store --gc
- run garbage collection
Synopsis
nix-store
--gc
[--print-roots
| --print-live
| --print-dead
] [--max-freed
bytes]
Description
Without additional flags, the operation --gc
performs a garbage
collection on the Nix store. That is, all paths in the Nix store not
reachable via file system references from a set of “roots”, are deleted.
The following suboperations may be specified:
-
--print-roots
This operation prints on standard output the set of roots used by the garbage collector.
-
--print-live
This operation prints on standard output the set of “live” store paths, which are all the store paths reachable from the roots. Live paths should never be deleted, since that would break consistency — it would become possible that applications are installed that reference things that are no longer present in the store.
-
--print-dead
This operation prints out on standard output the set of “dead” store paths, which is just the opposite of the set of live paths: any path in the store that is not live (with respect to the roots) is dead.
By default, all unreachable paths are deleted. The following options control what gets deleted and in what order:
-
--max-freed
bytesKeep deleting paths until at least bytes bytes have been deleted, then stop. The argument bytes can be followed by the multiplicative suffix
K
,M
,G
orT
, denoting KiB, MiB, GiB or TiB units.
The behaviour of the collector is also influenced by the
keep-outputs
and keep-derivations
settings in the Nix
configuration file.
By default, the collector prints the total number of freed bytes when it
finishes (or when it is interrupted). With --print-dead
, it prints the
number of bytes that would be freed.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Examples
To delete all unreachable paths, just do:
$ nix-store --gc
deleting `/nix/store/kq82idx6g0nyzsp2s14gfsc38npai7lf-cairo-1.0.4.tar.gz.drv'
...
8825586 bytes freed (8.42 MiB)
To delete at least 100 MiBs of unreachable paths:
$ nix-store --gc --max-freed $((100 * 1024 * 1024))
Name
nix-store --generate-binary-cache-key
- generate key pair to use for a binary cache
Synopsis
nix-store
--generate-binary-cache-key
key-name secret-key-file public-key-file
Description
This command generates an Ed25519 key pair that can be used to create a signed binary cache. It takes three mandatory parameters:
-
A key name, such as
cache.example.org-1
, that is used to look up keys on the client when it verifies signatures. It can be anything, but it’s suggested to use the host name of your cache (e.g.cache.example.org
) with a suffix denoting the number of the key (to be incremented every time you need to revoke a key). -
The file name where the secret key is to be stored.
-
The file name where the public key is to be stored.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Name
nix-store --import
- import Nix Archive into the store
Synopsis
nix-store
--import
Description
The operation --import
reads a serialisation of a set of store objects produced by nix-store --export
from standard input, and adds those store objects to the specified Nix store.
Paths that already exist in the target Nix store are ignored.
If a path refers to another path that doesn’t exist in the target Nix store, the import fails.
Note
For efficient transfer of closures to remote machines over SSH, use
nix-copy-closure
.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Examples
Example
Given a closure of GNU Hello as a file:
$ storePath="$(nix-build '<nixpkgs>' -I nixpkgs=channel:nixpkgs-unstable -A hello --no-out-link)" $ nix-store --export $(nix-store --query --requisites $storePath) > hello.closure
Import the closure into a remote SSH store using the
--store
option:$ nix-store --import --store ssh://alice@itchy.example.org < hello.closure
Name
nix-store --load-db
- import Nix database
Synopsis
nix-store
--load-db
Description
The operation --load-db
reads a dump of the Nix database created by
--dump-db
from standard input and loads it into the Nix database.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Name
nix-store --optimise
- reduce disk space usage
Synopsis
nix-store
--optimise
Description
The operation --optimise
reduces Nix store disk space usage by finding
identical files in the store and hard-linking them to each other. It
typically reduces the size of the store by something like 25-35%. Only
regular files and symlinks are hard-linked in this manner. Files are
considered identical when they have the same Nix Archive (NAR) serialisation:
that is, regular files must have the same contents and permission
(executable or non-executable), and symlinks must have the same
contents.
After completion, or when the command is interrupted, a report on the achieved savings is printed on standard error.
Use -vv
or -vvv
to get some progress indication.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Example
$ nix-store --optimise
hashing files in `/nix/store/qhqx7l2f1kmwihc9bnxs7rc159hsxnf3-gcc-4.1.1'
...
541838819 bytes (516.74 MiB) freed by hard-linking 54143 files;
there are 114486 files with equal contents out of 215894 files in total
Name
nix-store --print-env
- print the build environment of a derivation
Synopsis
nix-store
--print-env
drvpath
Description
The operation --print-env
prints out the environment of a derivation
in a format that can be evaluated by a shell. The command line arguments
of the builder are placed in the variable _args
.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Example
$ nix-store --print-env $(nix-instantiate '<nixpkgs>' -A firefox)
…
export src; src='/nix/store/plpj7qrwcz94z2psh6fchsi7s8yihc7k-firefox-12.0.source.tar.bz2'
export stdenv; stdenv='/nix/store/7c8asx3yfrg5dg1gzhzyq2236zfgibnn-stdenv'
export system; system='x86_64-linux'
export _args; _args='-e /nix/store/9krlzvny65gdc8s7kpb6lkx8cd02c25c-default-builder.sh'
Name
nix-store --query
- display information about store paths
Synopsis
nix-store
{--query
| -q
}
{--outputs
| --requisites
| -R
| --references
| --referrers
|
--referrers-closure
| --deriver
| -d
| --valid-derivers
|
--graph
| --tree
| --binding
name | -b
name | --hash
|
--size
| --roots
}
[--use-output
] [-u
] [--force-realise
] [-f
]
paths…
Description
The operation --query
displays various bits of information about the
store paths . The queries are described below. At most one query can be
specified. The default query is --outputs
.
The paths paths may also be symlinks from outside of the Nix store, to the Nix store. In that case, the query is applied to the target of the symlink.
Common query options
-
--use-output
/-u
For each argument to the query that is a store derivation, apply the query to the output path of the derivation instead.
-
--force-realise
/-f
Realise each argument to the query first (see
nix-store --realise
).
Queries
-
--outputs
Prints out the output paths of the store derivations paths. These are the paths that will be produced when the derivation is built.
-
--requisites
/-R
Prints out the closure of the store path paths.
This query has one option:
--include-outputs
Also include the existing output paths of store derivations, and their closures.
This query can be used to implement various kinds of deployment. A source deployment is obtained by distributing the closure of a store derivation. A binary deployment is obtained by distributing the closure of an output path. A cache deployment (combined source/binary deployment, including binaries of build-time-only dependencies) is obtained by distributing the closure of a store derivation and specifying the option
--include-outputs
. -
--references
Prints the set of references of the store paths paths, that is, their immediate dependencies. (For all dependencies, use
--requisites
.) -
--referrers
Prints the set of referrers of the store paths paths, that is, the store paths currently existing in the Nix store that refer to one of paths. Note that contrary to the references, the set of referrers is not constant; it can change as store paths are added or removed.
-
--referrers-closure
Prints the closure of the set of store paths paths under the referrers relation; that is, all store paths that directly or indirectly refer to one of paths. These are all the path currently in the Nix store that are dependent on paths.
-
--deriver
/-d
Prints the deriver that was used to build the store paths paths. If the path has no deriver (e.g., if it is a source file), or if the deriver is not known (e.g., in the case of a binary-only deployment), the string
unknown-deriver
is printed. The returned deriver is not guaranteed to exist in the local store, for example when paths were substituted from a binary cache. Use--valid-derivers
instead to obtain valid paths only. -
--valid-derivers
Prints a set of derivation files (
.drv
) which are supposed produce said paths when realized. Might print nothing, for example for source paths or paths subsituted from a binary cache. -
--graph
Prints the references graph of the store paths paths in the format of the
dot
tool of AT&T's Graphviz package. This can be used to visualise dependency graphs. To obtain a build-time dependency graph, apply this to a store derivation. To obtain a runtime dependency graph, apply it to an output path. -
--tree
Prints the references graph of the store paths paths as a nested ASCII tree. References are ordered by descending closure size; this tends to flatten the tree, making it more readable. The query only recurses into a store path when it is first encountered; this prevents a blowup of the tree representation of the graph.
-
--graphml
Prints the references graph of the store paths paths in the GraphML file format. This can be used to visualise dependency graphs. To obtain a build-time dependency graph, apply this to a store derivation. To obtain a runtime dependency graph, apply it to an output path.
-
--binding
name /-b
namePrints the value of the attribute name (i.e., environment variable) of the store derivations paths. It is an error for a derivation to not have the specified attribute.
-
--hash
Prints the SHA-256 hash of the contents of the store paths paths (that is, the hash of the output of
nix-store --dump
on the given paths). Since the hash is stored in the Nix database, this is a fast operation. -
--size
Prints the size in bytes of the contents of the store paths paths — to be precise, the size of the output of
nix-store --dump
on the given paths. Note that the actual disk space required by the store paths may be higher, especially on filesystems with large cluster sizes. -
--roots
Prints the garbage collector roots that point, directly or indirectly, at the store paths paths.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Examples
Print the closure (runtime dependencies) of the svn
program in the
current user environment:
$ nix-store --query --requisites $(which svn)
/nix/store/5mbglq5ldqld8sj57273aljwkfvj22mc-subversion-1.1.4
/nix/store/9lz9yc6zgmc0vlqmn2ipcpkjlmbi51vv-glibc-2.3.4
...
Print the build-time dependencies of svn
:
$ nix-store --query --requisites $(nix-store --query --deriver $(which svn))
/nix/store/02iizgn86m42q905rddvg4ja975bk2i4-grep-2.5.1.tar.bz2.drv
/nix/store/07a2bzxmzwz5hp58nf03pahrv2ygwgs3-gcc-wrapper.sh
/nix/store/0ma7c9wsbaxahwwl04gbw3fcd806ski4-glibc-2.3.4.drv
... lots of other paths ...
The difference with the previous example is that we ask the closure of
the derivation (-qd
), not the closure of the output path that contains
svn
.
Show the build-time dependencies as a tree:
$ nix-store --query --tree $(nix-store --query --deriver $(which svn))
/nix/store/7i5082kfb6yjbqdbiwdhhza0am2xvh6c-subversion-1.1.4.drv
+---/nix/store/d8afh10z72n8l1cr5w42366abiblgn54-builder.sh
+---/nix/store/fmzxmpjx2lh849ph0l36snfj9zdibw67-bash-3.0.drv
| +---/nix/store/570hmhmx3v57605cqg9yfvvyh0nnb8k8-bash
| +---/nix/store/p3srsbd8dx44v2pg6nbnszab5mcwx03v-builder.sh
...
Show all paths that depend on the same OpenSSL library as svn
:
$ nix-store --query --referrers $(nix-store --query --binding openssl $(nix-store --query --deriver $(which svn)))
/nix/store/23ny9l9wixx21632y2wi4p585qhva1q8-sylpheed-1.0.0
/nix/store/5mbglq5ldqld8sj57273aljwkfvj22mc-subversion-1.1.4
/nix/store/dpmvp969yhdqs7lm2r1a3gng7pyq6vy4-subversion-1.1.3
/nix/store/l51240xqsgg8a7yrbqdx1rfzyv6l26fx-lynx-2.8.5
Show all paths that directly or indirectly depend on the Glibc (C
library) used by svn
:
$ nix-store --query --referrers-closure $(ldd $(which svn) | grep /libc.so | awk '{print $3}')
/nix/store/034a6h4vpz9kds5r6kzb9lhh81mscw43-libgnomeprintui-2.8.2
/nix/store/15l3yi0d45prm7a82pcrknxdh6nzmxza-gawk-3.1.4
...
Note that ldd
is a command that prints out the dynamic libraries used
by an ELF executable.
Make a picture of the runtime dependency graph of the current user environment:
$ nix-store --query --graph ~/.nix-profile | dot -Tps > graph.ps
$ gv graph.ps
Show every garbage collector root that points to a store path that
depends on svn
:
$ nix-store --query --roots $(which svn)
/nix/var/nix/profiles/default-81-link
/nix/var/nix/profiles/default-82-link
/home/eelco/.local/state/nix/profiles/profile-97-link
Name
nix-store --read-log
- print build log
Synopsis
nix-store
{--read-log
| -l
} paths…
Description
The operation --read-log
prints the build log of the specified store
paths on standard output. The build log is whatever the builder of a
derivation wrote to standard output and standard error. If a store path
is not a derivation, the deriver of the store path is used.
Build logs are kept in /nix/var/log/nix/drvs
. However, there is no
guarantee that a build log is available for any particular store path.
For instance, if the path was downloaded as a pre-built binary through a
substitute, then the log is unavailable.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Example
$ nix-store --read-log $(which ktorrent)
building /nix/store/dhc73pvzpnzxhdgpimsd9sw39di66ph1-ktorrent-2.2.1
unpacking sources
unpacking source archive /nix/store/p8n1jpqs27mgkjw07pb5269717nzf5f8-ktorrent-2.2.1.tar.gz
ktorrent-2.2.1/
ktorrent-2.2.1/NEWS
...
Name
nix-store --realise
- build or fetch store objects
Synopsis
nix-store
{--realise
| -r
} paths… [--dry-run
]
Description
Each of paths is processed as follows:
- If the path leads to a store derivation:
- If it is not valid, substitute the store derivation file itself.
- Realise its output paths:
- Try to fetch from substituters the store objects associated with the output paths in the store derivation's closure.
- With content-addressed derivations (experimental): Determine the output paths to realise by querying content-addressed realisation entries in the Nix database.
- For any store paths that cannot be substituted, produce the required store objects:
- Realise all outputs of the derivation's dependencies
- Run the derivation's
builder
executable
- Otherwise, and if the path is not already valid: Try to fetch the associated store objects in the path's closure from substituters.
If no substitutes are available and no store derivation is given, realisation fails.
The resulting paths are printed on standard output. For non-derivation arguments, the argument itself is printed.
Special exit codes for build failure
1xx status codes are used when requested builds failed. The following codes are in use:
-
100
Generic build failureThe builder process returned with a non-zero exit code.
-
101
Build timeoutThe build was aborted because it did not complete within the specified
timeout
. -
102
Hash mismatchThe build output was rejected because it does not match the
outputHash
attribute of the derivation. -
104
Not deterministicThe build succeeded in check mode but the resulting output is not binary reproducible.
With the --keep-going
flag it's possible for multiple failures to occur.
In this case the 1xx status codes are or combined using
bitwise OR.
0b1100100
^^^^
|||`- timeout
||`-- output hash mismatch
|`--- build failure
`---- not deterministic
Options
-
--dry-run
Print on standard error a description of what packages would be built or downloaded, without actually performing the operation.
-
--ignore-unknown
If a non-derivation path does not have a substitute, then silently ignore it.
-
--check
This option allows you to check whether a derivation is deterministic. It rebuilds the specified derivation and checks whether the result is bitwise-identical with the existing outputs, printing an error if that’s not the case. The outputs of the specified derivation must already exist. When used with
-K
, if an output path is not identical to the corresponding output from the previous build, the new output path is left in/nix/store/name.check.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Examples
This operation is typically used to build store derivations produced by
nix-instantiate
:
$ nix-store --realise $(nix-instantiate ./test.nix)
/nix/store/31axcgrlbfsxzmfff1gyj1bf62hvkby2-aterm-2.3.1
This is essentially what nix-build
does.
To test whether a previously-built derivation is deterministic:
$ nix-build '<nixpkgs>' --attr hello --check -K
Use nix-store --read-log
to show the stderr and stdout of a build:
$ nix-store --read-log $(nix-instantiate ./test.nix)
Name
nix --repair-path
- re-download path from substituter
Synopsis
nix-store
--repair-path
paths…
Description
The operation --repair-path
attempts to “repair” the specified paths
by redownloading them using the available substituters. If no
substitutes are available, then repair is not possible.
Warning
During repair, there is a very small time window during which the old path (if it exists) is moved out of the way and replaced with the new path. If repair is interrupted in between, then the system may be left in a broken state (e.g., if the path contains a critical system component like the GNU C Library).
Example
$ nix-store --verify-path /nix/store/dj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13
path `/nix/store/dj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13' was modified!
expected hash `2db57715ae90b7e31ff1f2ecb8c12ec1cc43da920efcbe3b22763f36a1861588',
got `481c5aa5483ebc97c20457bb8bca24deea56550d3985cda0027f67fe54b808e4'
$ nix-store --repair-path /nix/store/dj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13
fetching path `/nix/store/d7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13'...
…
Name
nix-store --restore
- extract a Nix archive
Synopsis
nix-store
--restore
path
Description
The operation --restore
unpacks a Nix Archive (NAR) to path, which must
not already exist. The archive is read from standard input.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Name
nix-store --serve
- serve local Nix store over SSH
Synopsis
nix-store
--serve
[--write
]
Description
The operation --serve
provides access to the Nix store over stdin and
stdout, and is intended to be used as a means of providing Nix store
access to a restricted ssh user.
The following flags are available:
-
--write
Allow the connected client to request the realization of derivations. In effect, this can be used to make the host act as a remote builder.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Examples
To turn a host into a build server, the authorized_keys
file can be
used to provide build access to a given SSH public key:
$ cat <<EOF >>/root/.ssh/authorized_keys
command="nice -n20 nix-store --serve --write" ssh-rsa AAAAB3NzaC1yc2EAAAA...
EOF
Name
nix-store --verify-path
- check path contents against Nix database
Synopsis
nix-store
--verify-path
paths…
Description
The operation --verify-path
compares the contents of the given store
paths to their cryptographic hashes stored in Nix’s database. For every
changed path, it prints a warning message. The exit status is 0 if no
path has changed, and 1 otherwise.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Example
To verify the integrity of the svn
command and all its dependencies:
$ nix-store --verify-path $(nix-store --query --requisites $(which svn))
Name
nix-store --verify
- check Nix database for consistency
Synopsis
nix-store
--verify
[--check-contents
] [--repair
]
Description
The operation --verify
verifies the internal consistency of the Nix
database, and the consistency between the Nix database and the Nix
store. Any inconsistencies encountered are automatically repaired.
Inconsistencies are generally the result of the Nix store or database
being modified by non-Nix tools, or of bugs in Nix itself.
This operation has the following options:
-
--check-contents
Checks that the contents of every valid store path has not been altered by computing a SHA-256 hash of the contents and comparing it with the hash stored in the Nix database at build time. Paths that have been modified are printed out. For large stores,
--check-contents
is obviously quite slow. -
--repair
If any valid path is missing from the store, or (if
--check-contents
is given) the contents of a valid path has been modified, then try to repair the path by redownloading it. Seenix-store --repair-path
for details.
Options
The following options are allowed for all nix-store
operations, but may not always have an effect.
-
--add-root
pathCauses the result of a realisation (
--realise
and--force-realise
) to be registered as a root of the garbage collector. path will be created as a symlink to the resulting store path. In addition, a uniquely named symlink to path will be created in/nix/var/nix/gcroots/auto/
. For instance,$ nix-store --add-root /home/eelco/bla/result --realise ... $ ls -l /nix/var/nix/gcroots/auto lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result $ ls -l /home/eelco/bla/result lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10
Thus, when
/home/eelco/bla/result
is removed, the GC root in theauto
directory becomes a dangling symlink and will be ignored by the collector.Warning
Note that it is not possible to move or rename GC roots, since the symlink in the
auto
directory will still point to the old location.If there are multiple results, then multiple symlinks will be created by sequentially numbering symlinks beyond the first one (e.g.,
foo
,foo-2
,foo-3
, and so on).
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-
-
--no-build-output
/-Q
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses this behaviour. Note that the builder's standard output and error are always written to a log file in
prefix/nix/var/log/nix
. -
--max-jobs
/-j
numberSets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify
auto
to use the number of CPUs in the system. The default is specified by themax-jobs
configuration setting, which itself defaults to1
. A higher value is useful on SMP systems or to exploit I/O latency.Setting it to
0
disallows building on the local machine, which is useful when you want builds to happen only on remote builders. -
Sets the value of the
NIX_BUILD_CORES
environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attributeenableParallelBuilding
is set totrue
, the builder passes the-jN
flag to GNU Make. It defaults to the value of thecores
configuration setting, if set, or1
otherwise. The value0
means that the builder should use all available CPU cores in the system. -
Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the
max-silent-time
configuration setting.0
means no time-out. -
Sets the maximum number of seconds that a builder can run. The default is specified by the
timeout
configuration setting.0
means no timeout. -
--keep-going
/-k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
-
--keep-failed
/-K
Specifies that in case of a build failure, the temporary directory (usually in
/tmp
) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. -
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
-
When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail.
-
--arg
name valueThis option is accepted by
nix-env
,nix-instantiate
,nix-shell
andnix-build
. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g.,{ argName ? defaultValue }: ...
).With
--arg
, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.For instance, the top-level
default.nix
in Nixpkgs is actually a function:{ # The system (e.g., `i686-linux') for which to build the packages. system ? builtins.currentSystem ... }: ...
So if you call this Nix expression (e.g., when you do
nix-env --install --attr pkgname
), the function will be called automatically using the valuebuiltins.currentSystem
for thesystem
argument. You can override this using--arg
, e.g.,nix-env --install --attr pkgname --arg system \"i686-freebsd\"
. (Note that since the argument is a Nix string literal, you have to escape the quotes.) -
--argstr
name valueThis option is like
--arg
, only the value is not a Nix expression but a string. So instead of--arg system \"i686-linux\"
(the outer quotes are to keep the shell happy) you can say--argstr system i686-linux
. -
--attr
/-A
attrPathSelect an attribute from the top-level Nix expression being evaluated. (
nix-env
,nix-instantiate
,nix-build
andnix-shell
only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute pathxorg.xorgserver
would cause the expressione.xorg.xorgserver
to be used. Seenix-env --install
for some concrete examples.In addition to attribute names, you can also specify array indices. For instance, the attribute path
foo.3.bar
selects thebar
attribute of the fourth element of the array in thefoo
attribute of the top-level expression. -
--expr
/-E
Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (
nix-instantiate
,nix-build
andnix-shell
only.)For
nix-shell
, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to thenix-shell --packages
convenience flag instead. -
-I
/--include
pathAdd an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.
Paths added through
-I
take precedence over thenix-path
configuration setting and theNIX_PATH
environment variable. -
--option
name valueSet the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
-
Fix corrupted or missing store paths by redownloading or rebuilding them. Note that this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under
nix-store --repair-path
.
Note
See
man nix.conf
for overriding configuration settings with command line flags.
Common Environment Variables
Most Nix commands interpret the following environment variables:
-
Indicator that tells if the current environment was set up by
nix-shell
. It can have the valuespure
orimpure
. -
A colon-separated list of search path entries used to resolve lookup paths.
This environment variable overrides the value of the
nix-path
configuration setting.It can be extended using the
-I
option.Example
$ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos
If
NIX_PATH
is set to an empty string, resolving search paths will always fail.Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>' error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
-
Normally, the Nix store directory (typically
/nix/store
) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with/nix/store
resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where/nix/store
resolves differently. If you are sure that you’re not going to do that, you can setNIX_IGNORE_SYMLINK_STORE
to1
.Note that if you’re symlinking the Nix store so that you can put it on another file system than the root file system, on Linux you’re better off using
bind
mount points, e.g.,$ mkdir /nix $ mount -o bind /mnt/otherdisk/nix /nix
Consult the mount 8 manual page for details.
-
Overrides the location of the Nix store (default
prefix/store
). -
Overrides the location of the Nix static data directory (default
prefix/share
). -
Overrides the location of the Nix log directory (default
prefix/var/log/nix
). -
Overrides the location of the Nix state directory (default
prefix/var/nix
). -
Overrides the location of the system Nix configuration directory (default
prefix/etc/nix
). -
Applies settings from Nix configuration from the environment. The content is treated as if it was read from a Nix configuration file. Settings are separated by the newline character.
-
Overrides the location of the Nix user configuration files to load from.
The default are the locations according to the XDG Base Directory Specification. See the XDG Base Directories sub-section for details.
The variable is treated as a list separated by the
:
token. -
Use the specified directory to store temporary files. In particular, this includes temporary build directories; these can take up substantial amounts of disk space. The default is
/tmp
. -
This variable should be set to
daemon
if you want to use the Nix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Nix daemon's Unix socket is at some non-standard path, this variable should be set tounix://path/to/socket
. Otherwise, it should be left unset. -
If set to
1
, Nix will print some evaluation statistics, such as the number of values allocated. -
If set to
1
, Nix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions. -
If Nix has been configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. It defaults to 384 MiB. Setting it to a low value reduces memory consumption, but will increase runtime due to the overhead of garbage collection.
XDG Base Directories
Nix follows the XDG Base Directory Specification.
For backwards compatibility, Nix commands will follow the standard only when use-xdg-base-directories
is enabled.
New Nix commands (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files:
XDG_CONFIG_HOME
(default~/.config
)XDG_STATE_HOME
(default~/.local/state
)XDG_CACHE_HOME
(default~/.cache
)
Name
nix-env
- manipulate or query Nix user environments
Synopsis
nix-env
operation [options] [arguments…]
[--option
name value]
[--arg
name value]
[--argstr
name value]
[{--file
| -f
} path]
[{--profile
| -p
} path]
[--system-filter
system]
[--dry-run
]
Description
The command nix-env
is used to manipulate Nix user environments. User
environments are sets of software packages available to a user at some
point in time. In other words, they are a synthesised view of the
programs available in the Nix store. There may be many user
environments: different users can have different environments, and
individual users can switch between different environments.
nix-env
takes exactly one operation flag which indicates the
subcommand to be performed. The following operations are available:
--install
--upgrade
--uninstall
--set
--set-flag
--query
--switch-profile
--list-generations
--delete-generations
--switch-generation
--rollback
These pages can be viewed offline:
-
man nix-env-<operation>
.Example:
man nix-env-install
-
nix-env --help --<operation>
Example:
nix-env --help --install
Package sources
nix-env
can obtain packages from multiple sources:
- An attribute set of derivations from:
- The default Nix expression (by default)
- A Nix file, specified via
--file
- A profile, specified via
--from-profile
- A Nix expression that is a function which takes default expression as argument, specified via
--from-expression
- A store path
Selectors
Several operations, such as nix-env --query
and nix-env --install
, take a list of arguments that specify the packages on which to operate.
Packages are identified based on a name
part and a version
part of a symbolic derivation name:
name
: Everything up to but not including the first dash (-
) that is not followed by a letter.version
: The rest, excluding the separating dash.
Example
nix-env
parses the symbolic derivation nameapache-httpd-2.0.48
as:{ "name": "apache-httpd", "version": "2.0.48" }
Example
nix-env
parses the symbolic derivation namefirefox.*
as:{ "name": "firefox.*", "version": "" }
The name
parts of the arguments to nix-env
are treated as extended regular expressions and matched against the name
parts of derivation names in the package source.
The match is case-sensitive.
The regular expression can optionally be followed by a dash (-
) and a version number; if omitted, any version of the package will match.
For details on regular expressions, see regex(7).
Example
Common patterns for finding package names with
nix-env
:
firefox
Matches the package name
firefox
and any version.
firefox-32.0
Matches the package name
firefox
and version32.0
.
gtk\\+
Matches the package name
gtk+
. The+
character must be escaped using a backslash (\
) to prevent it from being interpreted as a quantifier, and the backslash must be escaped in turn with another backslash to ensure that the shell passes it on.
.\*
Matches any package name. This is the default for most commands.
'.*zip.*'
Matches any package name containing the string
zip
. Note the dots:'*zip*'
does not work, because in a regular expression, the character*
is interpreted as a quantifier.
'.*(firefox|chromium).*'
Matches any package name containing the strings
firefox
orchromium
.
Files
nix-env
operates on the following files.
Default Nix expression
The source for the default Nix expressions used by nix-env
:
~/.nix-defexpr
$XDG_STATE_HOME/nix/defexpr
ifuse-xdg-base-directories
is set totrue
.
It is loaded as follows:
- If the default expression is a file, it is loaded as a Nix expression.
- If the default expression is a directory containing a
default.nix
file, thatdefault.nix
file is loaded as a Nix expression. - If the default expression is a directory without a
default.nix
file, then its contents (both files and subdirectories) are loaded as Nix expressions. The expressions are combined into a single attribute set, each expression under an attribute with the same name as the original file or subdirectory. Subdirectories without adefault.nix
file are traversed recursively in search of more Nix expressions, but the names of these intermediate directories are not added to the attribute paths of the default Nix expression.
Then, the resulting expression is interpreted like this:
- If the expression is an attribute set, it is used as the default Nix expression.
- If the expression is a function, an empty set is passed as argument and the return value is used as the default Nix expression.
For example, if the default expression contains two files, foo.nix
and bar.nix
, then the default Nix expression will be equivalent to
{
foo = import ~/.nix-defexpr/foo.nix;
bar = import ~/.nix-defexpr/bar.nix;
}
The file manifest.nix
is always ignored.
The command nix-channel
places a symlink to the user's current channels profile in this directory.
This makes all subscribed channels available as attributes in the default expression.
User channel link
A symlink that ensures that nix-env
can find your channels:
~/.nix-defexpr/channels
$XDG_STATE_HOME/defexpr/channels
ifuse-xdg-base-directories
is set totrue
.
This symlink points to:
$XDG_STATE_HOME/profiles/channels
for regular users$NIX_STATE_DIR/profiles/per-user/root/channels
forroot
In a multi-user installation, you may also have ~/.nix-defexpr/channels_root
, which links to the channels of the root user.nix-env
: ../nix-env.md
Profiles
A directory that contains links to profiles managed by nix-env
and nix profile
:
$XDG_STATE_HOME/nix/profiles
for regular users$NIX_STATE_DIR/profiles/per-user/root
if the user isroot
A profile is a directory of symlinks to files in the Nix store.
Filesystem layout
Profiles are versioned as follows. When using a profile named path, path is a symlink to path-
N-link
, where N is the version of the profile.
In turn, path-
N-link
is a symlink to a path in the Nix store.
For example:
$ ls -l ~alice/.local/state/nix/profiles/profile*
lrwxrwxrwx 1 alice users 14 Nov 25 14:35 /home/alice/.local/state/nix/profiles/profile -> profile-7-link
lrwxrwxrwx 1 alice users 51 Oct 28 16:18 /home/alice/.local/state/nix/profiles/profile-5-link -> /nix/store/q69xad13ghpf7ir87h0b2gd28lafjj1j-profile
lrwxrwxrwx 1 alice users 51 Oct 29 13:20 /home/alice/.local/state/nix/profiles/profile-6-link -> /nix/store/6bvhpysd7vwz7k3b0pndn7ifi5xr32dg-profile
lrwxrwxrwx 1 alice users 51 Nov 25 14:35 /home/alice/.local/state/nix/profiles/profile-7-link -> /nix/store/mp0x6xnsg0b8qhswy6riqvimai4gm677-profile
Each of these symlinks is a root for the Nix garbage collector.
The contents of the store path corresponding to each version of the profile is a tree of symlinks to the files of the installed packages, e.g.
$ ll -R ~eelco/.local/state/nix/profiles/profile-7-link/
/home/eelco/.local/state/nix/profiles/profile-7-link/:
total 20
dr-xr-xr-x 2 root root 4096 Jan 1 1970 bin
-r--r--r-- 2 root root 1402 Jan 1 1970 manifest.nix
dr-xr-xr-x 4 root root 4096 Jan 1 1970 share
/home/eelco/.local/state/nix/profiles/profile-7-link/bin:
total 20
lrwxrwxrwx 5 root root 79 Jan 1 1970 chromium -> /nix/store/ijm5k0zqisvkdwjkc77mb9qzb35xfi4m-chromium-86.0.4240.111/bin/chromium
lrwxrwxrwx 7 root root 87 Jan 1 1970 spotify -> /nix/store/w9182874m1bl56smps3m5zjj36jhp3rn-spotify-1.1.26.501.gbe11e53b-15/bin/spotify
lrwxrwxrwx 3 root root 79 Jan 1 1970 zoom-us -> /nix/store/wbhg2ga8f3h87s9h5k0slxk0m81m4cxl-zoom-us-5.3.469451.0927/bin/zoom-us
/home/eelco/.local/state/nix/profiles/profile-7-link/share/applications:
total 12
lrwxrwxrwx 4 root root 120 Jan 1 1970 chromium-browser.desktop -> /nix/store/4cf803y4vzfm3gyk3vzhzb2327v0kl8a-chromium-unwrapped-86.0.4240.111/share/applications/chromium-browser.desktop
lrwxrwxrwx 7 root root 110 Jan 1 1970 spotify.desktop -> /nix/store/w9182874m1bl56smps3m5zjj36jhp3rn-spotify-1.1.26.501.gbe11e53b-15/share/applications/spotify.desktop
lrwxrwxrwx 3 root root 107 Jan 1 1970 us.zoom.Zoom.desktop -> /nix/store/wbhg2ga8f3h87s9h5k0slxk0m81m4cxl-zoom-us-5.3.469451.0927/share/applications/us.zoom.Zoom.desktop
…
Each profile version contains a manifest file:
manifest.nix
used bynix-env
.manifest.json
used bynix profile
(experimental).
User profile link
A symbolic link to the user's current profile:
~/.nix-profile
$XDG_STATE_HOME/nix/profile
ifuse-xdg-base-directories
is set totrue
.
By default, this symlink points to:
$XDG_STATE_HOME/nix/profiles/profile
for regular users$NIX_STATE_DIR/profiles/per-user/root/profile
forroot
The PATH
environment variable should include /bin
subdirectory of the profile link (e.g. ~/.nix-profile/bin
) for the user environment to be visible to the user.
The installer sets this up by default, unless you enable use-xdg-base-directories
.
Name
nix-env --delete-generations
- delete profile generations
Synopsis
nix-env
--delete-generations
generations
Description
This operation deletes the specified generations of the current profile.
generations can be a one of the following:
-
A list of generation numbers, each one a separate command-line argument.
Delete exactly the profile generations given by their generation number. Deleting the current generation is not allowed.
-
Delete all generations except the current one.
WARNING
Older and newer generations will be deleted by this operation.
One might expect this to just delete older generations than the curent one, but that is only true if the current generation is also the latest. Because one can roll back to a previous generation, it is possible to have generations newer than the current one. They will also be deleted.
-
The last number days
Example:
30d
Delete all generations created more than number days ago, except the most recent one of them. This allows rolling back to generations that were available within the specified period.
-
The last number generations up to the present
Example:
+5
Keep the last number generations, along with any newer than current.
Periodically deleting old generations is important to make garbage collection effective. The is because profiles are also garbage collection roots — any store object reachable from a profile is "alive" and ineligible for deletion.
Options
The following options are allowed for all nix-env
operations, but may not always have an effect.
-
--file
/-f
pathSpecifies the Nix expression (designated below as the active Nix expression) used by the
--install
,--upgrade
, and--query --available
operations to obtain derivations. The default is~/.nix-defexpr
.If the argument starts with
http://
orhttps://
, it is interpreted as the URL of a tarball that will be downloaded and unpacked to a temporary location. The tarball must include a single top-level directory containing at least a file nameddefault.nix
. -
--profile
/-p
pathSpecifies the profile to be used by those operations that operate on a profile (designated below as the active profile). A profile is a sequence of user environments called generations, one of which is the current generation.
-
--dry-run
For the
--install
,--upgrade
,--uninstall
,--switch-generation
,--delete-generations
and--rollback
operations, this flag will causenix-env
to print what would be done if this flag had not been specified, without actually doing it.--dry-run
also prints out which paths will be substituted (i.e., downloaded) and which paths will be built from source (because no substitute is available). -
--system-filter
systemBy default, operations such as
--query --available
show derivations matching any platform. This option allows you to use derivations for the specified platform system.
Common Options
Most Nix commands accept the following command-line options:
-
Prints out a summary of the command syntax and exits.
-
Prints out the Nix version number on standard output and exits.
-
--verbose
/-v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
-
0
“Errors only”Only print messages explaining why the Nix invocation failed.
-
1
“Informational”Print useful messages about what Nix is doing. This is the default.
-
2
“Talkative”Print more informational messages.
-
3
“Chatty”Print even more informational messages.
-
4
“Debug”Print debug information.
-
5
“Vomit”Print vast amounts of debug information.
-
-
Decreases the level of verbosity of diagnostic messages printed on standard error. This is the inverse option to
-v
/--verbose
.This option may be specified repeatedly. See the previous verbosity levels list.
-
--log-format
formatThis option can be used to change the output of the log format, with format being one of:
-
raw
This is the raw format, as outputted by nix-build.
-
internal-json
Outputs the logs in a structured manner.
Warning
While the schema itself is relatively stable, the format of the error-messages (namely of the
msg
-field) can change between releases. -
bar
Only display a progress bar during the builds.
-
bar-with-logs
Display the raw logs, with the progress bar at the bottom.
-