Introduction

Lix is an implementation of Nix, a powerful, purely functional package management system. 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. Lix 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

Lix 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 Lix 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

Lix has multi-user support. This means that non-privileged users can securely install software, and it is considered a bug if users can trample on each other. 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. Lix 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, Lix 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, Lix 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 tens of thousands of existing Unix packages, the Nix Packages collection (Nixpkgs).

Managing build environments

Lix 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

Lix runs on Linux and macOS.

NixOS

NixOS is a Linux distribution based on Nix technology. 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

Lix is released under the terms of the GNU LGPLv2.1 or (at your option) any later version.

Quick Start

FIXME(Lix): This chapter is quite outdated with respect to recommended practices in 2024 and needs updating. The commands in here will work, however, and the installation section is up to date.

For more updated guidance, see the links on https://lix.systems/resources/

This chapter is for impatient people who don't like reading documentation. For more in-depth information you are kindly referred to subsequent chapters.

  1. Install Lix:

    On Linux and macOS the easiest way to install Lix is to run the following shell command (as a user other than root):

    $ curl -sSf -L https://install.lix.systems/lix | sh -s -- install
    

    For systems that already have a Nix implementation installed, such as NixOS systems, read our install page

    The install script will use sudo, so make sure you have sufficient rights.

    For other installation methods, see here.

  2. See what installable packages are currently available in the channel:

    $ nix-env --query --available --attr-path
    nixpkgs.docbook_xml_dtd_43                    docbook-xml-4.3
    nixpkgs.docbook_xml_dtd_45                    docbook-xml-4.5
    nixpkgs.firefox                               firefox-33.0.2
    nixpkgs.hello                                 hello-2.9
    nixpkgs.libxslt                               libxslt-1.1.28
    …
    
  3. Install some packages from the channel:

    $ nix-env --install --attr nixpkgs.hello
    

    This should download pre-built packages; it should not build them locally (if it does, something went wrong).

  4. Test that they work:

    $ which hello
    /home/eelco/.nix-profile/bin/hello
    $ hello
    Hello, world!
    
  5. Uninstall a package:

    $ nix-env --uninstall hello
    
  6. You can also test a package without installing it:

    $ nix-shell --packages hello
    

    This builds or downloads GNU Hello and its dependencies, then drops you into a Bash shell where the hello command is present, all without affecting your normal environment:

    [nix-shell:~]$ hello
    Hello, world!
    
    [nix-shell:~]$ exit
    
    $ hello
    hello: command not found
    
  7. To keep up-to-date with the channel, do:

    $ nix-channel --update nixpkgs
    $ nix-env --upgrade '*'
    

    The latter command will upgrade each installed package for which there is a “newer” version (as determined by comparing the version numbers).

  8. If you're unhappy with the result of a nix-env action (e.g., an upgraded package turned out not to work properly), you can go back:

    $ nix-env --rollback
    
  9. You should periodically run the Lix garbage collector to get rid of unused packages, since uninstalls or upgrades don't actually delete them:

    $ nix-collect-garbage --delete-old
    

    N.B. on NixOS there is an option nix.gc.automatic to enable a systemd timer to automate this task.

Installation

See https://lix.systems/install/ for more details.

Supported Platforms

Lix is currently supported on the following platforms:

  • Linux (i686 (tier 2), x86_64 (tier 1), aarch64 (tier 1)).

  • macOS (x86_64 (tier 2 (issue to make tier 1)), aarch64 (tier 1)).

Tier 2 platforms aren't checked in CI, so may break without notice; such breakage is however considered a bug. We would like for them to work but they are a secondary priority.

Installing a Binary Distribution

See https://lix.systems/install/ for more details.

Installing Lix from Source

If no binary package is available or if you want to hack on Lix, you can build Lix from its Git repository.

Prerequisites

FIXME(meson): This section is very wrong with respect to meson and we have commented it out. We are sorry. The most current alternative to this section is to read package.nix and see which things are being depended on.

Obtaining the Source

The most recent sources of Lix 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://git.lix.systems/lix-project/lix

Likewise, specific releases can be obtained from the tags of the repository.

Building Lix from Source

FIXME(meson): This section is outdated for meson and has been commented out. See https://git.lix.systems/lix-project/lix/issues/258

Using Lix within Docker

Lix is available on the following two container registries:

To run the latest stable release of Lix with Docker run the following command:

~ » sudo podman run -it ghcr.io/lix-project/lix:latest
Trying to pull ghcr.io/lix-project/lix:latest...

bash-5.2# nix --version
nix (Lix, like Nix) 2.90.0

What is included in Lix's Docker image?

The official Docker image is created using nix2container (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 the nixpkgs that Lix was built with along with a minimal set of tools in the system profile:

  • bashInteractive
  • cacert.out
  • coreutils-full
  • curl
  • findutils
  • gitMinimal
  • gnugrep
  • gnutar
  • gzip
  • iana-etc
  • less
  • libxml2
  • lix
  • man
  • openssh
  • sqlite
  • wget
  • which

Docker image with the latest development version of Lix

FIXME: There are not currently images of development versions of Lix. Tracking issue: https://git.lix.systems/lix-project/lix/issues/381

You can build a Docker image from source yourself and copy it to either:

Podman: nix run '.#dockerImage.copyTo' containers-storage:lix

Docker: nix run '.#dockerImage.copyToDockerDaemon'

Then:

$ docker run -ti lix

Security

Lix 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 Lix in “multi-user mode”. In this model, all users can perform package management operations — for instance, every user can install software for themselves without requiring root privileges. Lix does its best to ensure that this is secure. For instance, it would be considered a serious security bug for one untrusted user to be able to overwrite a package used by another user with a Trojan horse.

Nevertheless, the Lix team does not consider multi-user mode a strong security boundary, and does not recommend running untrusted user-supplied Nix language code on privileged machines, even if it is secure to the best of our knowledge at any moment in time.

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 cannot meaningfully influence the execution of derivation builds such that they could inject malicious code into them without changing their (either input- or output- addressed) hash. 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 unprivileged system user accounts (usually named nixbld1, nixbld2, etc.). When an 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.

The buried lede in the above sentence is that currently, even in multi-user mode using a daemon, if executing as the user that owns the store, Lix directly manipulates the store unless --store daemon is specified. We intend to change this in the future.

The Lix team considers the goal of the sandbox to be primarily for preventing reproducibility mistakes, and does not consider multi-user mode to be a strong security boundary between users.

Do not evaluate or build untrusted, potentially-malicious, Nix language code on machines that you care deeply about maintaining user isolation on.

Although we would consider any sandbox escapes to be serious security bugs and we intend to fix them, we are not confident enough in the daemon's security to call the daemon a security boundary.

Trust model

There are two categories of users of the Lix daemon: trusted users and untrusted users. The Lix daemon only allows connections from users that are either trusted users, or are specified in, or are members of groups specified in, allowed-users in nix.conf. Trusted users are users and users of groups specified in trusted-users in nix.conf.

All users of the Lix daemon may do the following to bring things into the Nix store:

  • Users may load derivations and output-addressed files into the store with nix-store --add or through Nix language code.

  • Users may locally build derivations, either of the output-addressed or input-addressed variety, creating output paths.

    Note that fixed-output derivations only consider name and hash, so it is possible to write a fixed-output derivation for something important with a bogus hash and have it resolve to something else already built in the store.

    On systems with sandbox enabled (default on Linux; not yet on macOS), derivations are either:

    • Input-addressed, so they are run in the sandbox with no network access, with the following exceptions:

      • The (poorly named, since it is not just about chroot) property __noChroot is set on the derivation and sandbox is set to relaxed.
      • On macOS, the derivation property __darwinAllowLocalNetworking allows network access to localhost from input-addressed derivations regardless of the sandbox setting value. This property exists with such semantics because macOS has no network namespace equivalent to isolate individual processes' localhost networking.
    • Output-addressed, so they are run with network access but their result must match an expected hash.

    Trusted users may set any setting, including sandbox = false, so the sandbox state can be different at runtime from what is described in nix.conf for builds invoked with such settings.

  • Users may copy appropriately-signed derivation outputs into the store.

    By default, any paths copied into a store (such as by substitution) must have signatures from trusted-public-keys unless they are output-addressed.

    Unsigned paths may be copied into a store if require-sigs is disabled in the daemon's configuration (not default), or if the client is a trusted user and passed --no-check-sigs to nix copy.

  • Users may request that the daemon substitutes appropriately-signed derivation outputs from a binary cache in the daemon's substituters list.

    Untrusted clients may also specify additional values for substituters (via e.g. --extra-substituters on a Nix command) that are listed in trusted-substituters.

    A client could in principle substitute such paths itself then copy them to the daemon (see clause above) if they are appropriately signed but are not from a trusted substituter, however this is not implemented in the current Lix client to our knowledge, at the time of writing. This probably means that trusted-substituters is a redundant setting except insofar as such substitution would have to be done on the client rather than as root on the daemon; and it is highly defensible to not allow random usage of our HTTP client running as root.

The Lix daemon as a security non-boundary

The Lix team and wider community does not consider the Lix daemon to be a security boundary against malicious Nix language code.

Although we do our best to make it secure, we do not recommend sharing a Lix daemon with potentially malicious users. That means that public continuous integration (CI) builds of untrusted Nix code should not share builders with CI that writes into a cache used by trusted infrastructure.

For example, hydra.nixos.org, which is the builder for cache.nixos.org, does not execute untrusted Nix language code; a separate system, ofborg is used for CI of nixpkgs pull requests. The build output of pull request CI is never pushed to cache.nixos.org, and those systems are considered entirely untrusted.

This is because, among other things, the Lix sandbox is more susceptible to kernel exploits than Docker, which, unlike Lix, blocks nested user namespaces via seccomp in its default policy, and there have been many kernel bugs only exposed to unprivileged users via user namespaces allowing otherwise-root-only system calls. In general, the Lix sandbox is set up to be relatively unrestricted while maintaining its goals of building useful, reproducible software; security is not its primary goal.

The Lix sandbox is a custom non-rootless Linux container implementation that has not been audited to nearly the same degree as Docker and similar systems. Also, the Lix daemon is a complex and historied C++ executable running as root with very little privilege separation. All of this means that a security hole in the Lix daemon gives immediate root access. Systems like Docker (especially non-rootless Docker) should themselves probably not be used in a multi-tenant manner with mutually distrusting tenants, but the Lix daemon especially should not be used as such as of this writing.

The primary purpose of the sandbox is to strongly encourage packages to be reproducible, a goal which it is generally quite successful at.

Trusted users

Trusted users are permitted to set any setting and bypass security restrictions on the daemon. They are currently in widespread use for a couple of reasons such as remote builds (which we intend to fix).

Trusted users are effectively root on Nix daemons running as root (the default configuration) for at least the following reasons, and should be thus thought of as equivalent to passwordless sudo. This is not a comprehensive list.

  • They may copy an unsigned malicious built output into the store for systemd or anything else that will run as root, then when the system is upgraded, that path will be used from the local store rather than substituted.

  • They may set the following settings that are commands the daemon will run as root:

    • build-hook
    • diff-hook
    • pre-build-hook
    • post-build-hook
  • They may set build-users-group.

    In particular, they may set it to empty string, which runs builds as root with respect to the rest of the system (!!). We, too, think that is absurd and intend to not accept such a configuration. It is then simply an exercise to the reader to find a daemon that does SCM_CREDENTIALS over a unix(7) socket and lets you run commands as root, and mount it into the sandbox with extra-sandbox-paths.

    At the very least, the Lix daemon itself (since root is a trusted user by default) and probably systemd qualify for this.

  • They may set the builders list, which will have ssh run as root. We aren't sure if there is a way to abuse this for command execution but it's plausible.

Note that setting accept-flake-config allows arbitrary Nix flakes to set Nix settings in the nixConfig stanza. Do not set this setting or pass --accept-flake-config while executing untrusted Nix language code as a trusted user for the reasons above!

Build users

The build users are the special UIDs under which builds are performed. A build user is selected for a build by looking in the group specified by build-users-group, by default, nixbld, then a member of that group not currently executing a build is selected for the build. The build users should not be members of any other group.

There can never be more concurrent builds than the number of build users, unless using auto-allocate-uids (tracking issue).

If, for some reason, you need to create such users manually, the following command will create 10 build users on Linux:

$ 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

Running the daemon

The Nix daemon can be started manually as follows (as root):

# nix-daemon

In standard installations of Lix, the daemon is started by a systemd unit (Linux) or launchd service (macOS).

Environment Variables

To use Lix, 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

FIXME(Lix): This section is undoubtedly wrong due to the Lix installer being replaced. The definitely-wrong install section has been commented out.

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, Lix will install and use its own certificate bundle.

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 Lix installer will detect the presence of Nix configuration, and abort.

If you use the Lix 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 Lix installer has special handling for these proxy-related environment variables: http_proxy, https_proxy, ftp_proxy, no_proxy, HTTP_PROXY, HTTPS_PROXY, FTP_PROXY, NO_PROXY.

If any of these variables are set when running the Lix 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 Lix

FIXME(Lix): does Lix forward to the installer for nix upgrade-nix? Should it, if present? Lix should restart the daemon for you but currently doesn't (issue).

For instructions to switch to Lix, see https://lix.systems/install.

Lix may be upgraded by running nix upgrade-nix and then restarting the Nix daemon.

Restarting daemon on Linux

sudo systemctl daemon-reload && sudo systemctl restart nix-daemon

Restarting daemon on macOS

FIXME(Lix): Write instructions that, according to the beta installation guide do not sometimes crash macOS (?!)

Uninstalling Lix

FIXME(Lix): This section is outdated and commented out due to the Lix installer being replaced such that it has an actual uninstaller.

See https://git.lix.systems/lix-project/lix-installer#uninstalling for up-to-date uninstallation instructions using the installer.

This chapter discusses how to do package management with Lix, 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.

Basic Package Management

FIXME(Lix): This section does not document the most common modern practices in terms of avoiding channels, pinning, declarative software installation (see flakey-profile or home-manager or NixOS), or using flakes, etc. It is, however, likely correct at a technical level.

For more information on modern practices, see the resources page on the Lix site.

The main command for package management is nix-env. You can use it to install, upgrade, and erase packages, and to query what packages are installed or are available for installation.

In Nix systems, different users can have different “views” on the set of installed applications. That is, there might be lots of applications present on the system (possibly in many different versions), but users can have a specific selection of those active — where “active” just means that it appears in a directory in the user’s PATH. Such a view on the set of installed applications is called a user environment, which is just a directory tree consisting of symlinks to the files of the active applications.

Components are installed from a set of Nix expressions that tell Lix how to build those packages, including, if necessary, their dependencies. There is a very large collection of Nix expressions called the Nixpkgs package collection that contains packages ranging from basic development stuff such as GCC and Glibc, to end-user applications like Mozilla Firefox. (Lix is however not tied to the Nixpkgs package collection; you could write your own Nix expressions based on Nixpkgs, or completely new ones.)

You can manually download the latest version of Nixpkgs from https://github.com/NixOS/nixpkgs. However, it’s much more convenient to use the Nixpkgs channel, since it makes it easy to stay up to date with new versions of Nixpkgs. Nixpkgs is automatically added to your list of “subscribed” channels when you install Lix. If this is not the case for some reason, you can add it as follows:

$ nix-channel --add https://nixos.org/channels/nixpkgs-unstable
$ nix-channel --update

Note

On NixOS, you’re automatically subscribed to a NixOS channel corresponding to your NixOS major release (e.g. http://nixos.org/channels/nixos-21.11). A NixOS channel is identical to the Nixpkgs channel, except that it contains only Linux binaries and is updated only if a set of regression tests succeed.

You can view the set of available packages in Nixpkgs:

$ nix-env --query --available --attr-path
nixpkgs.aterm                       aterm-2.2
nixpkgs.bash                        bash-3.0
nixpkgs.binutils                    binutils-2.15
nixpkgs.bison                       bison-1.875d
nixpkgs.blackdown                   blackdown-1.4.2
nixpkgs.bzip2                       bzip2-1.0.2
…

The flag -q specifies a query operation, -a means that you want to show the “available” (i.e., installable) packages, as opposed to the installed packages, and -P prints the attribute paths that can be used to unambiguously select a package for installation (listed in the first column). If you downloaded Nixpkgs yourself, or if you checked it out from GitHub, then you need to pass the path to your Nixpkgs tree using the -f flag:

$ nix-env --query --available --attr-path --file /path/to/nixpkgs
aterm                               aterm-2.2
bash                                bash-3.0
…

where /path/to/nixpkgs is where you’ve unpacked or checked out Nixpkgs.

You can filter the packages by name:

$ nix-env --query --available --attr-path firefox
nixpkgs.firefox-esr                 firefox-91.3.0esr
nixpkgs.firefox                     firefox-94.0.1

and using regular expressions:

$ nix-env --query --available --attr-path 'firefox.*'

It is also possible to see the status of available packages, i.e., whether they are installed into the user environment and/or present in the system:

$ nix-env --query --available --attr-path --status
…
-PS  nixpkgs.bash                bash-3.0
--S  nixpkgs.binutils            binutils-2.15
IPS  nixpkgs.bison               bison-1.875d
…

The first character (I) indicates whether the package is installed in your current user environment. The second (P) indicates whether it is present on your system (in which case installing it into your user environment would be a very quick operation). The last one (S) indicates whether there is a so-called substitute for the package, which is Nix’s mechanism for doing binary deployment. It just means that Lix knows that it can fetch a pre-built package from somewhere (typically a network server) instead of building it locally.

You can install a package using nix-env --install --attr . For instance,

$ nix-env --install --attr nixpkgs.subversion

will install the package called subversion from nixpkgs channel (which is, of course, the Subversion version management system).

Note

When you ask Lix to install a package, it will first try to get it in pre-compiled form from a binary cache. By default, Lix will use the binary cache https://cache.nixos.org; it contains binaries for most packages in Nixpkgs. Only if no binary is available in the binary cache, Lix will build the package from source. So if nix-env -iA nixpkgs.subversion results in Lix building stuff from source, then either the package is not built for your platform by the Nixpkgs build servers, or your version of Nixpkgs is too old or too new. For instance, if you have a very recent checkout of Nixpkgs, then the Nixpkgs build servers may not have had a chance to build everything and upload the resulting binaries to https://cache.nixos.org. The Nixpkgs channel is only updated after all binaries have been uploaded to the cache, so if you stick to the Nixpkgs channel (rather than using a Git checkout of the Nixpkgs tree), you will get binaries for most packages.

Naturally, packages can also be uninstalled. Unlike when installing, you will need to use the derivation name (though the version part can be omitted), instead of the attribute path, as nix-env does not record which attribute was used for installing:

$ nix-env --uninstall subversion

Upgrading to a new version is just as easy. If you have a new release of nixpkgs, you can do:

$ nix-env --upgrade --attr nixpkgs.subversion

This will only upgrade Subversion if there is a “newer” version in the new set of Nix expressions, as defined by some pretty arbitrary rules regarding ordering of version numbers (which generally do what you’d expect of them). To just unconditionally replace Subversion with whatever version is in the Nix expressions, use -i instead of -u; -i will remove whatever version is already installed.

You can also upgrade all packages for which there are newer versions:

$ nix-env --upgrade

Sometimes it’s useful to be able to ask what nix-env would do, without actually doing it. For instance, to find out what packages would be upgraded by nix-env --upgrade , you can do

$ nix-env --upgrade --dry-run
(dry run; not doing anything)
upgrading `libxslt-1.1.0' to `libxslt-1.1.10'
upgrading `graphviz-1.10' to `graphviz-1.12'
upgrading `coreutils-5.0' to `coreutils-5.2.1'

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 Lix 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.

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

FIXME(Lix): This section documents outdated practices.

In particular, the Lix developers would not recommend using nix-serve as it is relatively-unmaintained Perl. The Lix developers would recommend instead using an s3 based cache (which is what https://cache.nixos.org is), and if it is desired to self-host it, use something like garage.

See the following projects:

  • attic - multi-tenant cache for larger deployments, using s3 as a backend.
  • harmonia - closer to a drop in replacement for use cases served by nix-serve

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 Lix 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 Lix to use your binary cache using --substituters (assuming you are a trusted user, see trusted-users in nix.conf), e.g.:

$ nix-env --install --attr nixpkgs.firefox --substituters http://avalon:8080/

The option substituters tells Lix 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, Lix 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 Lix 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/

Copying Closures via SSH

The command nix-copy-closure copies a Nix store path along with all its dependencies to or from another machine via the SSH protocol. It doesn’t copy store paths that are already present on the target machine. For example, the following command copies Firefox with all its dependencies:

$ nix-copy-closure --to alice@itchy.example.org $(type -p firefox)

See the manpage for nix-copy-closure for details.

With nix-store --export and nix-store --import you can write the closure of a store path (that is, the path and all its dependencies) to a file, and then unpack that file into another Nix store. For example,

$ nix-store --export $(nix-store --query --requisites $(type -p firefox)) > firefox.closure

writes the closure of Firefox to a file. You can then copy this file to another machine and install the closure:

$ nix-store --import < firefox.closure

Any store paths in the closure that are already present in the target store are ignored. It is also possible to pipe the export into another command, e.g. to copy and install a closure directly to/on another machine:

$ nix-store --export $(nix-store --query --requisites $(type -p firefox)) | bzip2 | \
    ssh alice@itchy.example.org "bunzip2 | nix-store --import"

However, nix-copy-closure is generally more efficient because it only copies paths that are not already present in the target Nix store.

Serving a Nix store via SSH

You can tell Lix 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 Lix usually uses, only using SSH instead of HTTP: if a store path P is needed, Lix 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 into ssh-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.

Serving a Nix store via S3

Lix has built-in support for storing and fetching store paths from Amazon S3 and S3-compatible services.

FIXME(Lix): document the correct setup to fetch from a s3 cache via HTTP rather than just through s3:// (which works, but forces you to remain s3-like on the client side)

In this example we will use the bucket named example-nix-cache.

Anonymous Reads to your S3-compatible binary cache

If your binary cache is publicly accessible and does not require authentication, the simplest and easiest way to use Lix with your S3 compatible binary cache is to use the HTTP URL for that cache.

For AWS S3 the binary cache URL for example bucket will be exactly https://example-nix-cache.s3.amazonaws.com or s3://example-nix-cache. For S3 compatible binary caches, consult that cache's documentation.

Your bucket will need the following bucket policy:

{
    "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": "*"
        }
    ]
}

Authenticated Reads to your S3 binary cache

For AWS S3 the binary cache URL for example bucket will be exactly s3://example-nix-cache.

Lix will use the default credential provider chain for authenticating requests to Amazon S3.

Lix supports authenticated reads from Amazon S3 and S3 compatible binary caches.

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

Lix support fully supports writing to Amazon S3 and S3 compatible buckets. The binary cache URL for our example bucket will be s3://example-nix-cache.

Lix will use the default credential provider chain for authenticating requests to Amazon S3.

Your account will need the following IAM policy to upload to the cache:

{
  "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

To upload with a specific credential profile for Amazon S3:

$ nix copy nixpkgs.hello \
  --to 's3://example-nix-cache?profile=cache-upload&region=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'

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. It 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

"hello world"

A string

''
  multi
   line
    string
''

A multi-line string. Strips common prefixed whitespace. Evaluates to "multi\n line\n string".

"hello ${ { a = "world"; }.a }"

"1 2 ${toString 3}"

"${pkgs.bash}/bin/sh"

String interpolation (expands to "hello world", "1 2 3", "/nix/store/<hash>-bash-<version>/bin/sh")

true, false

Booleans

null

Null value

123

An integer

3.141

A floating point number

/etc

An absolute path

./foo.png

A path relative to the file containing this Nix expression

~/.config

A home path. Evaluates to the "<user's home directory>/.config".

<nixpkgs>

Search path for Nix files. Value determined by $NIX_PATH environment variable.

Compound values

{ x = 1; y = 2; }

A set with attributes named x and y

{ foo.bar = 1; }

A nested set, equivalent to { foo = { bar = 1; }; }

rec { x = "foo"; y = x + "bar"; }

A recursive set, equivalent to { x = "foo"; y = "foobar"; }

[ "foo" "bar" "baz" ]

[ 1 2 3 ]

[ (f 1) { a = 1; b = 2; } [ "c" ] ]

Lists with three elements.

Operators

"foo" + "bar"

String concatenation

1 + 2

Integer addition

"foo" == "f" + "oo"

Equality test (evaluates to true)

"foo" != "bar"

Inequality test (evaluates to true)

!true

Boolean negation

{ x = 1; y = 2; }.x

Attribute selection (evaluates to 1)

{ x = 1; y = 2; }.z or 3

Attribute selection with default (evaluates to 3)

{ x = 1; y = 2; } // { z = 3; }

Merge two sets (attributes in the right-hand set taking precedence)

Control structures

if 1 + 1 == 2 then "yes!" else "no!"

Conditional expression

assert 1 + 1 == 2; "yes!"

Assertion check (evaluates to "yes!").

let x = "foo"; y = "bar"; in x + y

Variable definition

with builtins; head [ 1 2 3 ]

Add all attributes from the given set to the scope (evaluates to 1)

Functions (lambdas)

x: x + 1

A function that expects an integer and returns it increased by 1

x: y: x + y

Curried function, equivalent to x: (y: x + y). Can be used like a function that takes two arguments and returns their sum.

(x: x + 1) 100

A function call (evaluates to 101)

let inc = x: x + 1; in inc (inc (inc 100))

A function bound to a variable and subsequently called by name (evaluates to 103)

{ x, y }: x + y

A function that expects a set with required attributes x and y and concatenates them

{ x, y ? "bar" }: x + y

A function that expects a set with required attribute x and optional y, using "bar" as default value for y

{ x, y, ... }: x + y

A function that expects a set with required attributes x and y and ignores any other attributes

{ x, y } @ args: x + y

args @ { x, y }: x + y

A function that expects a set with required attributes x and y, and binds the whole set to args

Built-in functions

import ./foo.nix

Load and return Nix expression in given file

map (x: x + x) [ 1 2 3 ]

Apply a function to every element of a list (evaluates to [ 2 4 6 ])

Data Types

Primitives

  • 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 special characters " and \ and the character sequence ${ must be escaped by prefixing them with a backslash (\). Newlines, carriage returns and tabs can be written as \n, \r and \t, respectively.

    You can include the results of other expressions into a string by enclosing them in ${ }, a feature known as string interpolation.

    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 that the whitespace and newline following the opening '' is ignored if there is no non-whitespace text on the initial line.

    Indented strings support string interpolation.

    Since ${ and '' have special meaning in indented strings, you need a way to quote them. $ can be escaped by prefixing it with '' (that is, two single quotes), i.e., ''$. '' can be escaped by prefixing it with ', i.e., '''. $ removes any special meaning from the following $. Linefeed, carriage-return and tab characters can be written as ''\n, ''\r, ''\t, and ''\ escapes any other character.

    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, e.g., /bin/sh or ./builder.sh. A path 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. If the file name is relative, i.e., if it does not begin with a slash, it is made absolute at parse time relative to the directory of the Nix expression that contained it. For instance, if a Nix expression in /foo/bar/bla.nix refers to ../xyzzy/fnord.nix, the absolute path is /foo/xyzzy/fnord.nix.

    If the first component of a path is a ~, it is interpreted as if the rest of the path were relative to the user's home directory. e.g. ~/foo would be equivalent to /home/edolstra/foo for a user whose home directory is /home/edolstra.

    Paths can also be specified between angle brackets, e.g. <nixpkgs>. This means that the directories listed in the environment variable NIX_PATH will be searched for the given file or directory name.

    When an interpolated string evaluates to a path, the path is first copied into the Nix store and the resulting string is the store path of the newly created store object.

    For instance, evaluating "${./foo.txt}" will cause foo.txt in the current directory to be copied into the Nix store and result in the string "/nix/store/<hash>-foo.txt".

    Note that 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.

    Paths themselves, except those in angle brackets (< >), support string interpolation.

    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 division operation. ./a.${foo}/b.${bar} is a path.

  • Boolean

    Booleans with values true and false.

  • Null

    The null value, denoted as null.

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.

Attribute Set

An attribute set is a collection of name-value-pairs (called attributes) enclosed in curly brackets ({ }).

An attribute name can be an identifier or a string. An identifier must start with a letter (a-z, A-Z) or underscore (_), and can otherwise contain letters (a-z, A-Z), numbers (0-9), underscores (_), apostrophes ('), or dashes (-).

name = identifier | string
identifier ~ [a-zA-Z_][a-zA-Z0-9_'-]*

Names and values are separated by an equal sign (=). Each value is an arbitrary expression terminated by a semicolon (;).

attrset = { [ name = expr ; ]... }

Attributes can appear in any order. An attribute name may only occur once.

Example:

{
  x = 123;
  text = "Hello";
  y = f { bla = 456; };
}

This defines a set with attributes named x, text, y.

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.

Language Constructs

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 the let 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.

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 and z. 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 accepts y and z.

  • 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 as a, using args.a, which was given as an additional attribute to the function.

    Warning

    args@ binds the name args 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:

  1. 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 to true but the db4 argument set to null, then the evaluation fails.

    Note that -> is the logical implication Boolean operation.

  2. 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.

  3. 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.)

  4. 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 ...

Comments

Comments can be single-line, started with a # character, or inline/multi-line, enclosed within /* ... */.

Context-dependent keywords

__curPos

A quasi-constant which will be replaced with an attribute set describing the location where __curPos was used, with attributes file, line, and column. For example, import ./file.nix will result in

{
  column = 1;
  file = "/path/to/some/file.nix";
  line = 1;
}

assuming file.nix contains nothing but __curPos.

In context without a source file (such as nix-repl), it will always be replaced with null:

nix-repl> __curPos
null

While it may vaguely look like a builtin, this is a very different beast that is handled directly by the parser. It thus cannot be shadowed, bound to a different name, and is also not available under builtins.

nix-repl> let __curPos = "no"; in __curPos
null

Despite this __curPos, much like or, may still be used as an identifier, it is only treated specially when it appears as an unqualified name:

nix-repl> { __curPos = 1; }.__curPos
1
or

or is used in Attribute selection, where it is a keyword.

However, it is not a keyword in some other contexts, and can be used as a binding name in attribute sets, let-bindings, non-initial function application position, and as a label in attribute paths.

Its use as anything other than a keyword is discouraged.

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 string is an interpolated string, and an expression inside is an interpolated expression.

Interpolated expressions must evaluate to one of the following:

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}).

Path

Rather than writing

./. + "/" + foo + "-" + bar + ".nix"

or

./. + "/${foo}-${bar}.nix"

you can instead write

./${foo}-${bar}.nix

Attribute name

Attribute names can be created dynamically with string interpolation:

let name = "foo"; in
{
  ${name} = "bar";
}
{ foo = "bar"; }

Operators

NameSyntaxAssociativityPrecedence
Attribute selectionattrset . attrpath [ or expr ]none1
Function applicationfunc exprleft2
Arithmetic negation- numbernone3
Has attributeattrset ? attrpathnone4
List concatenationlist ++ listright5
Multiplicationnumber * numberleft6
Divisionnumber / numberleft6
Subtractionnumber - numberleft7
Additionnumber + numberleft7
String concatenationstring + stringleft7
Path concatenationpath + pathleft7
Path and string concatenationpath + stringleft7
String and path concatenationstring + pathleft7
Logical negation (NOT)! boolnone8
Updateattrset // attrsetright9
Less thanexpr < exprnone10
Less than or equal toexpr <= exprnone10
Greater thanexpr > exprnone10
Greater than or equal toexpr >= exprnone10
Equalityexpr == exprnone11
Inequalityexpr != exprnone11
Logical conjunction (AND)bool && boolleft12
Logical disjunction (OR)bool || boolleft13
Logical implicationbool -> boolnone14

Attribute selection

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.

An attribute path is a dot-separated list of attribute names.

attrpath = name [ . name ]...

Has attribute

attrset ? attrpath

Test whether attribute set attrset contains the attribute denoted by attrpath. The result is a Boolean value.

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

string + string

Concatenate two strings and merge their string contexts.

Path concatenation

path + path

Concatenate two paths. The result is a path.

Path and string concatenation

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

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

attrset1 // attrset2

Update attribute set attrset1 with names and values from attrset2.

The returned attribute set will have of all 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:

comparisonimplementation
a <= b! ( b < a )
a > bb < 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.

Derivations

The most important built-in function is derivation, which is used to describe a single derivation (a build task). It takes as input a set, the attributes of which specify the inputs of the build.

  • There must be an attribute named system whose value must be a string specifying a Nix system type, such as "i686-linux" or "x86_64-darwin". (To figure out your system type, run nix -vv --version.) The build can only be performed on a machine and operating system matching the system type. (Nix can automatically forward builds for other platforms by forwarding them to other machines.)

  • There must be an attribute named name whose value must be a string. This is used as a symbolic name for the package by nix-env, and it is appended to the output paths of the derivation.

  • There must be an attribute named builder that identifies the program that is executed to perform the build. It can be either a derivation or a source (a local file reference, e.g., ./builder.sh).

  • Every attribute is passed as an environment variable to the builder. Attribute values are translated to environment variables as follows:

    • Strings and numbers are just passed verbatim.

    • 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; its default output path is put in the environment variable.

    • Lists of the previous types are also allowed. They are simply concatenated, separated by spaces.

    • true is passed as the string 1, false and null are passed as an empty string.

  • The optional attribute args specifies command-line arguments to be passed to the builder. It should be a list.

  • The optional attribute outputs specifies a list of symbolic outputs of the derivation. By default, a derivation produces a single output path, denoted as out. However, derivations can produce multiple output paths. This is useful because it allows outputs to be downloaded or garbage-collected separately. For instance, imagine a library package that provides a dynamic library, header files, and documentation. A program that links against the 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:

    outputs = [ "lib" "headers" "doc" ];
    

    This will cause Lix to pass environment variables lib, headers and doc to the builder containing the intended store paths of each output. The builder would typically do something like

    ./configure \
      --libdir=$lib/lib \
      --includedir=$headers/include \
      --docdir=$doc/share/doc
    

    for an Autoconf-style package. You can refer to each output of a derivation by selecting it as an attribute, e.g.

    buildInputs = [ pkg.lib pkg.headers ];
    

    The first element of outputs determines the default output. Thus, you could also write

    buildInputs = [ pkg pkg.headers ];
    

    since pkg is equivalent to pkg.lib.

The function mkDerivation in the Nixpkgs standard environment is a wrapper around derivation that adds a default value for system and always uses Bash as the builder, to which the supplied builder is passed as a command-line argument. See the Nixpkgs manual for details.

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, when HOME 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 to true 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, the name attribute and the output name. (The output name is omitted if it’s out.)

  • If an output path already exists, it is removed. Also, locks are acquired to prevent multiple Lix 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, Lix 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, Lix registers them as dependencies of the output paths.

  • After the build, Lix 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 and setgid bits are cleared. Setuid and setgid programs are not currently supported by Lix. This is because the Lix 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 attribute allowedReferences 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 to allowedReferences, 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 that foobar itself doesn't introduce any other dependency itself.

  • disallowedReferences
    The optional attribute disallowedReferences 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 to disallowedReferences, 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 on foobar.

  • 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 by nix-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 file libfoo-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 (a cpio 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 line

    impureEnvVars = [ "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 the nix-build.

  • outputHash; outputHashAlgo; outputHashMode
    These attributes declare that the derivation is a so-called fixed-output derivation, which means that a cryptographic hash of the output is already known in advance. When the build of a fixed-output derivation finishes, Lix computes the cryptographic hash of the output and compares it to the hash declared with these attributes. If there is a mismatch, the build 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* and name attributes, while all other attributes are ignored for the purpose of computing the output path. (The name 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 outputHashAlgo attribute specifies the hash algorithm used to compute the hash. It can currently be "sha1", "sha256" or "sha512".

    The outputHashMode attribute determines how the hash is computed. It must be one of the following two values:

    • "flat"
      The output must be a non-executable regular file. If it isn’t, the build fails. The hash is simply computed over the contents of that file (so it’s equal to what Unix commands like sha256sum or sha1sum produce).

      This is the default.

    • "recursive"
      The hash is computed over the NAR archive dump of the output (i.e., the result of nix-store --dump). In this case, the output can be anything, including a directory tree.

    The outputHash attribute, finally, must be a string containing the hash in either hexadecimal or base-32 notation. (See the nix-hash command for information about converting to and from base-32 notation.)

  • __contentAddressed

    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 and outputHashAlgo like for fixed-output derivations (see above).

  • passAsFile
    A list of names of attributes that should be passed via files rather than environment variables. For example, if you have

    passAsFile = ["big"];
    big = "a very long string";
    

    then when the builder runs, the environment variable bigPath will contain the absolute path to a temporary file containing a very long string. That is, for any attribute x listed in passAsFile, Lix will pass an environment variable xPath 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 to true and distributed building is enabled, then, if possible, the derivation will be built locally instead of forwarded to a remote machine. This is appropriate for trivial builders where the cost of doing a download or remote build would exceed the cost of building locally.

  • allowSubstitutes
    If this attribute is set to false, then Lix will always build this derivation; it will not try to substitute its outputs. This is useful for very trivial derivations (such as writeText in Nixpkgs) that are cheaper to build than to substitute from a binary cache.

    You may disable the effects of this attibute by enabling the always-allow-substitutes configuration option in Lix.

    Note

    You need to have a builder configured which satisfies the derivation’s system attribute, since the derivation cannot be substituted. Thus it is usually a good idea to align system with builtins.currentSystem when setting allowSubstitutes to false. For most trivial derivations this should be the case.

  • __structuredAttrs
    If the special attribute __structuredAttrs is set to true, the other derivation attributes are serialised into a file in JSON format. The environment variable NIX_ATTRS_JSON_FILE points to the exact location of that file both in a build and a nix-shell. This obviates the need for passAsFile 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, Lix 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 a nix-shell. This includes non-nested (associative) arrays. For example, the attribute hardening.format = true ends up as the Bash associative array element ${hardening[format]}.

  • outputChecks
    When using structured attributes, the outputChecks attribute allows defining checks per-output.

    In addition to allowedReferences, allowedRequisites, disallowedReferences and disallowedRequisites, 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;
    };
    
  • unsafeDiscardReferences\

    When using structured attributes, the attribute unsafeDiscardReferences is an attribute set with a boolean value for each output name. If set to true, 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.

Built-in Constants

These constants are built into the Nix language evaluator:

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
currentSystem (string)

The value of the eval-system or else system configuration option.

It can be used to set the system attribute for builtins.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 evaluate builtins.currentTime in the same second.

Note

Not available in pure evaluation mode.

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
langVersion (integer)

The legacy version of the Nix language. Always is 6 on Lix, matching Nix 2.18.

Code in the Nix language should use other means of feature detection like detecting the presence of builtins, rather than trying to find the version of the Nix implementation, as there may be other Nix implementations with different feature combinations.

If the feature you want to write compatibility code for cannot be detected by any means, please file a Lix bug.

nixPath (list)

The search path used to resolve angle bracket path lookups.

Angle bracket expressions can be desugared using this and builtins.findFile:

<nixpkgs>

is equivalent to:

builtins.findFile builtins.nixPath "nixpkgs"
nixVersion (string)

Legacy version of Nix. Always returns "2.18.3-lix" on Lix.

Code in the Nix language should use other means of feature detection like detecting the presence of builtins, rather than trying to find the version of the Nix implementation, as there may be other Nix implementations with different feature combinations.

If the feature you want to write compatibility code for cannot be detected by any means, please file a Lix bug.

null (null)

Primitive value.

The name null is not special, and can be shadowed:

nix-repl> let null = 1; in null
1
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"
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

Things which might be mistaken for constants

__curPos

This is not a constant but a context-dependent keyword

Built-in Functions

This section lists the functions built into the Nix language evaluator. All built-in functions are available through the global builtins constant.

For convenience, some built-ins can be accessed directly:

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 returns true for all elements of list, and false otherwise.

any pred list

Return true if the function pred returns true for at least one element of list, and false 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 s

Return the base name of the string s, that is, everything following the final slash in the string. This is similar to the GNU basename command.

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 argument v.

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, and 1 if s1 is newer than s2. The version comparison algorithm is the same as the one used by nix-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".

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, and false 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.

fetchClosure args

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 a fromPath, use nix 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 correct toPath 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 Lix configuration.

builtins.storePath

fetchClosure is similar to builtins.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 configure trusted-public-keys to ensure their authenticity.

This function is only available if the fetch-closure experimental feature is enabled.

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: basename of the URL)

    The name of the directory the repo should be exported to in the store.

  • rev (default: the tip of ref)

    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.

    By default, the ref value is prefixed with refs/heads/. As of 2.3.0, Nix will not prefix refs/heads/ if ref starts with refs/.

  • submodules (default: false)

    A Boolean parameter that specifies whether submodules should be checked out.

  • shallow (default: false)

    A Boolean parameter that specifies whether fetching from a shallow remote repository is allowed. This still performs a full clone of what is available on the remote.

  • allRefs

    Whether to fetch all references of the repository. With this argument being true, it's possible to load a rev from any ref (by default only revs from the specified ref are supported).

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";
    }
    

    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 or rev 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 by git 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 with gzip, bzip2 or xz. The top-level path component of the files in the tarball is removed, so it is best if the tarball contains a single directory at top level. 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 line tarball-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 attribute sha256, 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.

fetchurl url

Download the specified URL and return the path of the downloaded file.

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. Since filterSource 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. Use builtins.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. With filterSource 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 returns true 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

Look up the given path with the given search path.

A search path is represented list of attribute sets with two attributes, prefix, and path. prefix is a relative path. path denotes a file system location; the exact syntax depends on the command line interface.

Examples of search path attribute sets:

  • {
      prefix = "nixos-config";
      path = "/etc/nixos/configuration.nix";
    }
    
  • {
      prefix = "";
      path = "/nix/var/nix/profiles/per-user/root/channels";
    }
    

The lookup algorithm checks each entry until a match is found, returning a path value of the match.

This is the process for each entry: If the lookup path matches prefix, then the remainder of the lookup path (the "suffix") is searched for within the directory denoted by patch. Note that the path 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.

The syntax

<nixpkgs>

is equivalent to:

builtins.findFile builtins.nixPath "nixpkgs"
flakeRefToString attrs

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"

This function is only available if the flakes experimental feature is enabled.

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' (x: y: x + y) 0 [1 2 3] evaluates to 6. The return value of each application of op 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

Take an attrset with values named startSet and operator in order to return a list of attrsets by starting with the startSet and recursively applying the operator function to each item. The attrsets in the startSet and the attrsets produced by operator must contain a value named key which is comparable. The result is produced by calling operator for each item with a value for key that has not been called yet including newly produced items. The function terminates when no new items are produced. The resulting list of attrsets contains only attrsets with a unique key. For 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 a getEnv "HOME" to locate the user’s home directory.)

getFlake args

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

This function is only available if the flakes experimental feature is enabled.

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 returns true if set has an attribute named s, and false 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 with getContext.

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 losing 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.

The value path can be a path, a string, or an attribute set with an __toString attribute or a outPath attribute (as derivations or flake inputs typically have).

If path is a directory, the file default.nix in that directory is loaded.

Evaluation aborts if the file doesn’t exist or contains an incorrect Nix expression. import implements Nix’s module system: you can put any Nix expression (such as a set or a function) in a separate file, and use it from Nix expressions in other files.

Note

Unlike some languages, import is a regular function in Nix. Paths using the angle bracket syntax (e.g., import <foo>) are normal path values.

A Nix expression loaded by import must not contain any free variables (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. For instance, if you have a calling expression

rec {
  x = 123;
  y = import ./foo.nix;
}

then the following foo.nix will give an error:

x + 456

since x is not in scope in foo.nix. If you want x to be available in foo.nix, you should pass it as a function argument:

rec {
  x = 123;
  y = import ./foo.nix x;
}

and

x: x + 456

(The function argument doesn’t have to be called x in foo.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, and false otherwise.

isBool e

Return true if e evaluates to a bool, and false otherwise.

isFloat e

Return true if e evaluates to a float, and false otherwise.

isFunction e

Return true if e evaluates to a function, and false otherwise.

isInt e

Return true if e evaluates to an integer, and false otherwise.

isList e

Return true if e evaluates to a list, and false otherwise.

isNull e

Return true if e evaluates to null, and false otherwise.

This is equivalent to e == null.

isPath e

Return true if e evaluates to a path, and false otherwise.

isString e

Return true if e evaluates to a string, and false otherwise.

length e

Return the length of the list e.

lessThan e1 e2

Return true if the number e1 is less than the number e2, and false 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 attribute value 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.

outputOf derivation-reference output-name

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 select drv.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.

This function is only available if the dynamic-derivations experimental feature is enabled.

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

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"; }

This function is only available if the flakes experimental feature is enabled.

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 returned true, and a list named wrong, containing the elements for which it returned false. 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 by builtins.filterSource, with the same semantics.

  • recursive
    When false, when path 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 to fetchurl. Defaults to true.

  • 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 allows builtins.path to be used even when the pure-eval nix config option is on.

pathExists path

Return true if the path path exists at evaluation time, and false 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 file B and another directory C, then builtins.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, and false 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.

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 length 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, and if start + len lies beyond the end of the string, 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 second to last elements of a list; 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 calling tail 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 for abort).

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 expression configFile (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 and bar.

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 the path and war 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 with toXML, 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 ③ by toXML 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 syntax xsltproc ${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 to true and the --debugger flag is given, the interactive debugger will be started when trace is called (like break).

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.

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) and value, equalling e if successful and false otherwise. tryEval will only prevent errors created by throw or assert from being thrown. Errors tryEval will not catch are for example those created by abort and type errors generated by builtins. Also note that this doesn't evaluate e deeply, so let e = { x = throw ""; }; in (builtins.tryEval e).success will be true. Using builtins.deepSeq one can get the expected result: let e = { x = throw ""; }; in (builtins.tryEval (builtins.deepSeq e e)).success will be false.

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.

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 of f.

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" ]; };
}

This section lists advanced topics related to builds and builds performance

Remote Builds

Lix supports remote builds, where a local Lix installation can forward Nix builds to other machines. This allows multiple builds to be performed in parallel and allows Lix 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, Lix 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.

Warning

If you are building via the Lix daemon (default on Linux and macOS), it is the Lix daemon user account (that is, root) that should have SSH access to a user (not necessarily root) on the remote machine.

Furthermore, root needs to have the public host keys for the remote system in its .ssh/known_hosts. To add them to known_hosts for root, do ssh-keyscan USER@HOST | sudo tee -a ~root/.ssh/known_hosts.

If you can’t or don’t want to configure root to be able to access the remote machine, you can use a private Nix store instead by passing e.g. --store ~/my-nix when running a Nix command from the local machine.

The list of remote machines can be specified on the command line or in the Lix configuration file. The former is convenient for testing. 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 builders separated by a semicolon or a newline, e.g.

  --builders 'ssh://mac x86_64-darwin ; ssh://beastie x86_64-freebsd'

Each machine specification consists of the following elements, separated by spaces. Only the first element is required. To leave a field at its default, set it to -.

  1. The URI of the remote store in the format ssh://[username@]hostname, e.g. ssh://nix@mac or ssh://mac. For backward compatibility, ssh:// may be omitted. The hostname may be an alias defined in your ~/.ssh/config.

  2. A comma-separated list of Nix platform type identifiers, such as x86_64-darwin. It is possible for a machine to support multiple platform types, e.g., i686-linux,x86_64-linux. If omitted, this defaults to the local platform type.

  3. The SSH identity file to be used to log in to the remote machine. If omitted, SSH will use its regular identities.

  4. The maximum number of builds that Lix will execute in parallel on the machine. Typically this should be equal to the number of CPU cores. For instance, the machine itchy in the example will execute up to 8 builds in parallel.

  5. The “speed factor”, indicating the relative speed of the machine. If there are multiple machines of the right type, Lix will prefer the fastest, taking load into account.

  6. A comma-separated list of supported features. If a derivation has the requiredSystemFeatures attribute, then Lix will only perform the derivation on a machine that has the specified features. For instance, the attribute

    requiredSystemFeatures = [ "kvm" ];
    

    will cause the build to be performed on a machine that has the kvm feature.

  7. A comma-separated list of mandatory features. A machine will only be used to build a derivation if all of the machine’s mandatory features appear in the derivation’s requiredSystemFeatures attribute.

  8. The (base64-encoded) public host key of the remote machine. If omitted, SSH will use its regular known-hosts file. Specifically, the field is calculated via base64 -w0 /etc/ssh/ssh_host_ed25519_key.pub.

For example, the machine specification

nix@scratchy.labs.cs.uu.nl  i686-linux      /home/nix/.ssh/id_scratchy_auto        8 1 kvm
nix@itchy.labs.cs.uu.nl     i686-linux      /home/nix/.ssh/id_scratchy_auto        8 2
nix@poochie.labs.cs.uu.nl   i686-linux      /home/nix/.ssh/id_scratchy_auto        1 2 kvm benchmark

specifies several machines that can perform i686-linux builds. However, poochie will only do builds that have the attribute

requiredSystemFeatures = [ "benchmark" ];

or

requiredSystemFeatures = [ "benchmark" "kvm" ];

itchy cannot do builds that require kvm, but scratchy does support such builds. For regular builds, itchy will be preferred over scratchy because it has a higher speed factor.

Remote builders can also be configured in nix.conf, e.g.

builders = ssh://mac x86_64-darwin ; ssh://beastie x86_64-freebsd

Finally, remote builders can be configured in a separate configuration file included in builders via the syntax @file. For example,

builders = @/etc/nix/machines

causes the list of machines in /etc/nix/machines to be included. (This is the default.)

If you want the builders to use caches, you likely want to set the option builders-use-substitutes in your local nix.conf.

To build only on remote builders and disable building on the local machine, you can use the option --max-jobs 0.

Tuning Cores and Jobs

Lix 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. Lix will still substitute from binary caches, and build remotely if remote builders are configured.

  • cores
    Suggests how many cores each derivation should use. Similar to make -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-jobscoresNIX_BUILD_CORESMaximum ProcessesResult
1242424One derivation will be built at a time, each one can use 24 cores. Undersold if a job can’t use 24 cores.
46624Four derivations will be built at once, each given access to six cores.
12667212 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.
24112424 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.
2402457624 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 Lix'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, Lix 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, Lix 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 Lix daemon's log, we will now see:

For derivation /nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv:
1c1
< 8108
---
> 30204

Using --check with --keep-failed will cause Lix 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. Lix has copied the build results to that directory where you can examine it.

Note

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 Lix 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 Lix 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, 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 to nix store sign. Nix guarantees the paths will not contain any spaces, however a store path might contain glob characters. The set -f disables globbing in the shell.

Then make sure the hook program is executable by the root user:

# chmod +x /etc/nix/upload-to-cache.sh

Updating Lix 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 Lix 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 Lix.

Common Options

Most commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 Lix.

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.

  • --no-out-link

    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.

  • --dry-run

    Show what store paths would be built or downloaded.

  • --out-link / -o outlink

    Change 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 failure

    The builder process returned with a non-zero exit code.

  • 101 Build timeout

    The build was aborted because it did not complete within the specified timeout.

  • 102 Hash mismatch

    The build output was rejected because it does not match the outputHash attribute of the derivation.

  • 104 Not deterministic

    The 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 cmd
    In 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 to exit is implicitly added to the command, so the shell will exit after running the command. To prevent this, add return at the end; e.g. --command "echo Hello; return" will print Hello and then drop you into the interactive shell. This can be useful for doing any additional initialisation.

  • --run cmd
    Like --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 regexp
    Do 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 and DISPLAY, 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 names libjpeg and openjdk are present.

  • -i interpreter
    The chained script interpreter to be invoked by nix-shell. Only applicable in #!-scripts (described below).

  • --keep name
    When a --pure shell is started, keep the listed environment variables.

Common Options

Most commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 the bash found in PATH if not found.

Common Environment Variables

Most commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 python --packages python pythonPackages.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 ]; } ""

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:

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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 NAR (Nix ARchive) 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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 specified store paths to standard output in a format that can be imported into another Nix store with nix-store --import. This is like nix-store --dump, except that the NAR archive produced by that command doesn’t contain the necessary meta-information to allow it to be imported into another Nix store (namely, the set of references of the path).

This command does not produce a closure of the specified paths, so if a store path references other store paths that are missing in the target Nix store, the import will fail.

Options

The following options are allowed for all nix-store operations, but may not always have an effect.

  • --add-root path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 copy a whole closure, do something like:

$ nix-store --export $(nix-store --query --requisites paths) > out

To import the whole closure again, run:

$ nix-store --import < out

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 bytes
    Keep 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 or T, 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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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:

  1. 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).

  2. The file name where the secret key is to be stored.

  3. 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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 paths produced by nix-store --export from standard input and adds those store paths to the Nix store. Paths that already exist in the Nix store are ignored. If a path refers to another path that doesn’t exist in the Nix store, the import fails.

Options

The following options are allowed for all nix-store operations, but may not always have an effect.

  • --add-root path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 --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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 NAR archive 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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 name
    Prints 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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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:
    1. If it is not valid, substitute the store derivation file itself.
    2. Realise its output paths:
    • Try to fetch from substituters the store objects associated with the output paths in the store derivation's closure.
    • For any store paths that cannot be substituted, produce the required store objects. This involves first realising all outputs of the derivation's dependencies and then running 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 failure

    The builder process returned with a non-zero exit code.

  • 101 Build timeout

    The build was aborted because it did not complete within the specified timeout.

  • 102 Hash mismatch

    The build output was rejected because it does not match the outputHash attribute of the derivation.

  • 104 Not deterministic

    The 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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 NAR archive 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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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. See nix-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 path

    Causes 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 the auto 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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:

These pages can be viewed offline:

  • man nix-env-<operation>.

    Example: man nix-env-install

  • nix-env --help --<operation>

    Example: nix-env --help --install

Selectors

Several commands, such as nix-env --query and nix-env --install , take a list of arguments that specify the packages on which to operate. These are extended regular expressions that must match the entire name of the package. (For details on regular expressions, see regex(7).) 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. Here are some examples:

  • firefox
    Matches the package name firefox and any version.

  • firefox-32.0
    Matches the package name firefox and version 32.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 or chromium.

Files

nix-env operates on the following files.

Default Nix expression

The source for the default Nix expressions used by nix-env:

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, that default.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 a default.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.

A symlink that ensures that nix-env can find your channels:

This symlink points to:

  • $XDG_STATE_HOME/profiles/channels for regular users
  • $NIX_STATE_DIR/profiles/per-user/root/channels for root

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 is root

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 Lix 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:

A symbolic link to the user's current profile:

By default, this symlink points to:

  • $XDG_STATE_HOME/nix/profiles/profile for regular users
  • $NIX_STATE_DIR/profiles/per-user/root/profile for root

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:

  • <number>...:
    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.

  • The special value old

    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.

  • <number>d:
    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.

  • +<number>:
    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 path
    Specifies 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:// 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.

  • --profile / -p path
    Specifies 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 cause nix-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 system
    By 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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_PROFILE
    Location of the Nix profile. Defaults to the target of the symlink ~/.nix-profile, if it exists, or /nix/var/nix/profiles/default otherwise.

Common Environment Variables

Most commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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

Delete explicit generation numbers

$ nix-env --delete-generations 3 4 8

Delete the generations numbered 3, 4, and 8, so long as the current active generation is not any of those.

Keep most-recent by count (number of generations)

$ nix-env --delete-generations +5

Suppose 30 is the current generation, and we currently have generations numbered 20 through 32.

Then this command will delete generations 20 through 25 (<= 30 - 5), and keep generations 26 through 31 (> 30 - 5).

Keep most-recent by time (number of days)

$ nix-env --delete-generations 30d

This command will delete all generations older than 30 days, except for the generation that was active 30 days ago (if it currently exists).

Delete all older

$ nix-env --profile other_profile --delete-generations old

Name

nix-env --install - add packages to user environment

Synopsis

nix-env {--install | -i} args… [{--prebuilt-only | -b}] [{--attr | -A}] [--from-expression] [-E] [--from-profile path] [--preserve-installed | -P] [--remove-all | -r]

Description

The install operation creates a new user environment, based on the current generation of the active profile, to which a set of store paths described by args is added. The arguments args map to store paths in a number of possible ways:

  • By default, args is a set of derivation names denoting derivations in the active Nix expression. These are realised, and the resulting output paths are installed. Currently installed derivations with a name equal to the name of a derivation being added are removed unless the option --preserve-installed is specified.

    If there are multiple derivations matching a name in args that have the same name (e.g., gcc-3.3.6 and gcc-4.1.1), then the derivation with the highest priority is used. A derivation can define a priority by declaring the meta.priority attribute. This attribute should be a number, with a higher value denoting a lower priority. The default priority is 5.

    If there are multiple matching derivations with the same priority, then the derivation with the highest version will be installed.

    You can force the installation of multiple derivations with the same name by being specific about the versions. For instance, nix-env --install gcc-3.3.6 gcc-4.1.1 will install both version of GCC (and will probably cause a user environment conflict!).

  • If --attr (-A) is specified, the arguments are attribute paths that select attributes from the top-level Nix expression. This is faster than using derivation names and unambiguous. To find out the attribute paths of available packages, use nix-env --query --available --attr-path .

  • If --from-profile path is given, args is a set of names denoting installed store paths in the profile path. This is an easy way to copy user environment elements from one profile to another.

  • If --from-expression is given, args are Nix functions that are called with the active Nix expression as their single argument. The derivations returned by those function calls are installed. This allows derivations to be specified in an unambiguous way, which is necessary if there are multiple derivations with the same name.

  • If args are store derivations, then these are realised, and the resulting output paths are installed.

  • If args are store paths that are not store derivations, then these are realised and installed.

  • By default all outputs are installed for each derivation. That can be reduced by setting meta.outputsToInstall.

Flags

  • --prebuilt-only / -b
    Use only derivations for which a substitute is registered, i.e., there is a pre-built binary available that can be downloaded in lieu of building the derivation. Thus, no packages will be built from source.

  • --preserve-installed / -P
    Do not remove derivations with a name matching one of the derivations being installed. Usually, trying to have two versions of the same package installed in the same generation of a profile will lead to an error in building the generation, due to file name clashes between the two versions. However, this is not the case for all packages.

  • --remove-all / -r
    Remove all previously installed packages first. This is equivalent to running nix-env --uninstall '.*' first, except that everything happens in a single transaction.

Options

The following options are allowed for all nix-env operations, but may not always have an effect.

  • --file / -f path
    Specifies 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:// 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.

  • --profile / -p path
    Specifies 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 cause nix-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 system
    By 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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_PROFILE
    Location of the Nix profile. Defaults to the target of the symlink ~/.nix-profile, if it exists, or /nix/var/nix/profiles/default otherwise.

Common Environment Variables

Most commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 install a package using a specific attribute path from the active Nix expression:

$ nix-env --install --attr gcc40mips
installing `gcc-4.0.2'
$ nix-env --install --attr xorg.xorgserver
installing `xorg-server-1.2.0'

To install a specific version of gcc using the derivation name:

$ nix-env --install gcc-3.3.2
installing `gcc-3.3.2'
uninstalling `gcc-3.1'

Using attribute path for selecting a package is preferred, as it is much faster and there will not be multiple matches.

Note the previously installed version is removed, since --preserve-installed was not specified.

To install an arbitrary version:

$ nix-env --install gcc
installing `gcc-3.3.2'

To install all derivations in the Nix expression foo.nix:

$ nix-env --file ~/foo.nix --install '.*'

To copy the store path with symbolic name gcc from another profile:

$ nix-env --install --from-profile /nix/var/nix/profiles/foo gcc

To install a specific [store derivation] (typically created by nix-instantiate):

$ nix-env --install /nix/store/fibjb1bfbpm5mrsxc4mh2d8n37sxh91i-gcc-3.4.3.drv

To install a specific output path:

$ nix-env --install /nix/store/y3cgx0xj1p4iv9x0pnnmdhr8iyg741vk-gcc-3.4.3

To install from a Nix expression specified on the command-line:

$ nix-env --file ./foo.nix --install --expr \
    'f: (f {system = "i686-linux";}).subversionWithJava'

I.e., this evaluates to (f: (f {system = "i686-linux";}).subversionWithJava) (import ./foo.nix), thus selecting the subversionWithJava attribute from the set returned by calling the function defined in ./foo.nix.

A dry-run tells you which paths will be downloaded or built from source:

$ nix-env --file '<nixpkgs>' --install --attr hello --dry-run
(dry run; not doing anything)
installing ‘hello-2.10’
this path will be fetched (0.04 MiB download, 0.19 MiB unpacked):
  /nix/store/wkhdf9jinag5750mqlax6z2zbwhqb76n-hello-2.10
  ...

To install Firefox from the latest revision in the Nixpkgs/NixOS 14.12 channel:

$ nix-env --file https://github.com/NixOS/nixpkgs/archive/nixos-14.12.tar.gz --install --attr firefox

Name

nix-env --list-generations - list profile generations

Synopsis

nix-env --list-generations

Description

This operation print a list of all the currently existing generations for the active profile. These may be switched to using the --switch-generation operation. It also prints the creation date of the generation, and indicates the current generation.

Options

The following options are allowed for all nix-env operations, but may not always have an effect.

  • --file / -f path
    Specifies 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:// 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.

  • --profile / -p path
    Specifies 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 cause nix-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 system
    By 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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_PROFILE
    Location of the Nix profile. Defaults to the target of the symlink ~/.nix-profile, if it exists, or /nix/var/nix/profiles/default otherwise.

Common Environment Variables

Most commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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-env --list-generations
  95   2004-02-06 11:48:24
  96   2004-02-06 11:49:01
  97   2004-02-06 16:22:45
  98   2004-02-06 16:24:33   (current)

Name

nix-env --query - display information about packages

Synopsis

nix-env {--query | -q} names… [--installed | --available | -a] [{--status | -s}] [{--attr-path | -P}] [--no-name] [{--compare-versions | -c}] [--system] [--drv-path] [--out-path] [--description] [--meta] [--xml] [--json] [{--prebuilt-only | -b}] [{--attr | -A} attribute-path]

Description

The query operation displays information about either the store paths that are installed in the current generation of the active profile (--installed), or the derivations that are available for installation in the active Nix expression (--available). It only prints information about derivations whose symbolic name matches one of names.

The derivations are sorted by their name attributes.

Source selection

The following flags specify the set of things on which the query operates.

  • --installed
    The query operates on the store paths that are installed in the current generation of the active profile. This is the default.

  • --available; -a
    The query operates on the derivations that are available in the active Nix expression.

Queries

The following flags specify what information to display about the selected derivations. Multiple flags may be specified, in which case the information is shown in the order given here. Note that the name of the derivation is shown unless --no-name is specified.

  • --xml
    Print the result in an XML representation suitable for automatic processing by other tools. The root element is called items, which contains a item element for each available or installed derivation. The fields discussed below are all stored in attributes of the item elements.

  • --json
    Print the result in a JSON representation suitable for automatic processing by other tools.

  • --prebuilt-only / -b
    Show only derivations for which a substitute is registered, i.e., there is a pre-built binary available that can be downloaded in lieu of building the derivation. Thus, this shows all packages that probably can be installed quickly.

  • --status; -s
    Print the status of the derivation. The status consists of three characters. The first is I or -, indicating whether the derivation is currently installed in the current generation of the active profile. This is by definition the case for --installed, but not for --available. The second is P or -, indicating whether the derivation is present on the system. This indicates whether installation of an available derivation will require the derivation to be built. The third is S or -, indicating whether a substitute is available for the derivation.

  • --attr-path; -P
    Print the attribute path of the derivation, which can be used to unambiguously select it using the --attr option available in commands that install derivations like nix-env --install. This option only works together with --available

  • --no-name
    Suppress printing of the name attribute of each derivation.

  • --compare-versions / -c
    Compare installed versions to available versions, or vice versa (if --available is given). This is useful for quickly seeing whether upgrades for installed packages are available in a Nix expression. A column is added with the following meaning:

    • < version
      A newer version of the package is available or installed.

    • = version
      At most the same version of the package is available or installed.

    • > version
      Only older versions of the package are available or installed.

    • - ?
      No version of the package is available or installed.

  • --system
    Print the system attribute of the derivation.

  • --drv-path
    Print the path of the store derivation.

  • --out-path
    Print the output path of the derivation.

  • --description
    Print a short (one-line) description of the derivation, if available. The description is taken from the meta.description attribute of the derivation.

  • --meta
    Print all of the meta-attributes of the derivation. This option is only available with --xml or --json.

Options

The following options are allowed for all nix-env operations, but may not always have an effect.

  • --file / -f path
    Specifies 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:// 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.

  • --profile / -p path
    Specifies 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 cause nix-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 system
    By 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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_PROFILE
    Location of the Nix profile. Defaults to the target of the symlink ~/.nix-profile, if it exists, or /nix/var/nix/profiles/default otherwise.

Common Environment Variables

Most commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 show installed packages:

$ nix-env --query
bison-1.875c
docbook-xml-4.2
firefox-1.0.4
MPlayer-1.0pre7
ORBit2-2.8.3
…

To show available packages:

$ nix-env --query --available
firefox-1.0.7
GConf-2.4.0.1
MPlayer-1.0pre7
ORBit2-2.8.3
…

To show the status of available packages:

$ nix-env --query --available --status
-P- firefox-1.0.7   (not installed but present)
--S GConf-2.4.0.1   (not present, but there is a substitute for fast installation)
--S MPlayer-1.0pre3 (i.e., this is not the installed MPlayer, even though the version is the same!)
IP- ORBit2-2.8.3    (installed and by definition present)
…

To show available packages in the Nix expression foo.nix:

$ nix-env --file ./foo.nix --query --available
foo-1.2.3

To compare installed versions to what’s available:

$ nix-env --query --compare-versions
...
acrobat-reader-7.0 - ?      (package is not available at all)
autoconf-2.59      = 2.59   (same version)
firefox-1.0.4      < 1.0.7  (a more recent version is available)
...

To show all packages with “zip” in the name:

$ nix-env --query --available '.*zip.*'
bzip2-1.0.6
gzip-1.6
zip-3.0
…

To show all packages with “firefox” or “chromium” in the name:

$ nix-env --query --available '.*(firefox|chromium).*'
chromium-37.0.2062.94
chromium-beta-38.0.2125.24
firefox-32.0.3
firefox-with-plugins-13.0.1
…

To show all packages in the latest revision of the Nixpkgs repository:

$ nix-env --file https://github.com/NixOS/nixpkgs/archive/master.tar.gz --query --available

Name

nix-env --rollback - set user environment to previous generation

Synopsis

nix-env --rollback

Description

This operation switches to the “previous” generation of the active profile, that is, the highest numbered generation lower than the current generation, if it exists. It is just a convenience wrapper around --list-generations and --switch-generation.

Options

The following options are allowed for all nix-env operations, but may not always have an effect.

  • --file / -f path
    Specifies 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:// 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.

  • --profile / -p path
    Specifies 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 cause nix-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 system
    By 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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_PROFILE
    Location of the Nix profile. Defaults to the target of the symlink ~/.nix-profile, if it exists, or /nix/var/nix/profiles/default otherwise.

Common Environment Variables

Most commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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-env --rollback
switching from generation 92 to 91
$ nix-env --rollback
error: no generation older than the current (91) exists

Name

nix-env --set-flag - modify meta attributes of installed packages

Synopsis

nix-env --set-flag name value drvnames

Description

The --set-flag operation allows meta attributes of installed packages to be modified. There are several attributes that can be usefully modified, because they affect the behaviour of nix-env or the user environment build script:

  • priority can be changed to resolve filename clashes. The user environment build script uses the meta.priority attribute of derivations to resolve filename collisions between packages. Lower priority values denote a higher priority. For instance, the GCC wrapper package and the Binutils package in Nixpkgs both have a file bin/ld, so previously if you tried to install both you would get a collision. Now, on the other hand, the GCC wrapper declares a higher priority than Binutils, so the former’s bin/ld is symlinked in the user environment.

  • keep can be set to true to prevent the package from being upgraded or replaced. This is useful if you want to hang on to an older version of a package.

  • active can be set to false to “disable” the package. That is, no symlinks will be generated to the files of the package, but it remains part of the profile (so it won’t be garbage-collected). It can be set back to true to re-enable the package.

Options

The following options are allowed for all nix-env operations, but may not always have an effect.

  • --file / -f path
    Specifies 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:// 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.

  • --profile / -p path
    Specifies 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 cause nix-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 system
    By 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-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 path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-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 the bar attribute of the fourth element of the array in the foo 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 and nix-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 the nix-shell --packages convenience flag instead.

  • -I path

    Add an entry to the Nix expression search path. This option may be given multiple times. Paths added through -I take precedence over NIX_PATH.

  • --option name value

    Set the Lix configuration option name to value. This overrides settings in the Lix configuration file (see nix.conf(5)).

  • --repair

    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 commands in Lix interpret the following environment variables:

  • IN_NIX_SHELL
    Indicator that tells if the current environment was set up by nix-shell. It can have the values pure or impure.

  • NIX_PATH
    A colon-separated list of directories used to look up the location of Nix expressions using paths enclosed in angle brackets (i.e., <path>), e.g. /home/eelco/Dev:/etc/nixos. It can be extended using the -I option.

    If NIX_PATH is not set at all, Lix will fall back to the following list in impure and unrestricted evaluation mode:

    1. $HOME/.nix-defexpr/channels
    2. nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs
    3. /nix/var/nix/profiles/per-user/root/channels

    If NIX_PATH is set to an empty string, resolving search paths will always fail. For example, attempting to use <nixpkgs> will produce:

    error: file 'nixpkgs' was not found in the Nix search path
    
  • NIX_IGNORE_SYMLINK_STORE
    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 set NIX_IGNORE_SYMLINK_STORE to 1.

    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.

  • NIX_STORE_DIR
    Overrides the location of the Nix store (default prefix/store).

  • NIX_DATA_DIR
    Overrides the location of the Lix static data directory (default prefix/share).

  • NIX_LOG_DIR
    Overrides the location of the Lix log directory (default prefix/var/log/nix).

  • NIX_STATE_DIR
    Overrides the location of the Lix state directory (default prefix/var/nix).

  • NIX_CONF_DIR
    Overrides the location of the system Lix configuration directory (default prefix/etc/nix).

  • NIX_CONFIG
    Applies settings from Lix configuration from the environment. The content is treated as if it was read from a Lix configuration file. Settings are separated by the newline character.

  • NIX_USER_CONF_FILES
    Overrides the location of the Lix 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.

  • TMPDIR
    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.

  • NIX_REMOTE
    This variable should be set to daemon if you want to use the Lix daemon to execute Nix operations. This is necessary in multi-user Nix installations. If the Lix daemon's Unix socket is at some non-standard path, this variable should be set to unix://path/to/socket. Otherwise, it should be left unset.

  • NIX_SHOW_STATS
    If set to 1, Lix will print some evaluation statistics, such as the number of values allocated.

  • NIX_COUNT_CALLS
    If set to 1, Lix will print how often functions were called during Nix expression evaluation. This is useful for profiling your Nix expressions.

  • GC_INITIAL_HEAP_SIZE
    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

Lix follows the XDG Base Directory Specification.

For backwards compatibility, commands in Lix 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 prevent the currently installed Firefox from being upgraded:

$ nix-env --set-flag keep true firefox

After this, nix-env --upgrade will ignore Firefox.

To disable the currently installed Firefox, then install a new Firefox while the old remains part of the profile:

$ nix-env --query
firefox-2.0.0.9 (the current one)

$ nix-env --preserve-installed --install firefox-2.0.0.11
installing `firefox-2.0.0.11'
building path(s) `/nix/store/myy0y59q3ig70dgq37jqwg1j0rsapzsl-user-environment'
collision between `/nix/store/...-firefox-2.0.0.11/bin/firefox'
  and `/nix/store/...-firefox-2.0.0.9/bin/firefox'.
(i.e., can’t have two active at the same time)

$ nix-env --set-flag active false firefox
setting flag on `firefox-2.0.0.9'

$ nix-env --preserve-installed --install firefox-2.0.0.11
installing `firefox-2.0.0.11'

$ nix-env --query
firefox-2.0.0.11 (the enabled one)
firefox-2.0.0.9 (the disabled one)

To make files from binutils take precedence over files from gcc:

$ nix-env --set-flag priority 5 binutils
$ nix-env --set-flag priority 10 gcc

Name

nix-env --set - set profile to contain a specified derivation

Synopsis

nix-env --set drvname

Description

The --set operation modifies the current generation of a profile so that it contains exactly the specified derivation, and nothing else.

Options

The following options are allowed for all nix-env operations, but may not always have an effect.

  • --file / -f path
    Specifies 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:// 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.

  • --profile / -p path
    Specifies 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 cause nix-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 system
    By 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 commands in Lix accept the following command-line options:

  • --help

    Prints out a summary of the command syntax and exits.

  • --version

    Prints out the Lix version number on standard output and exits.

  • --verbose / -v

    Increases the level of verbosity of diagnostic messages printed on standard error. For each Lix 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 Lix invocation failed.

    • 1 “Informational”

      Print useful messages about what Lix 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.

  • --quiet

    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 format

    This 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 Lix 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 number

    Sets the maximum number of build jobs that Lix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. 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.

  • --cores

    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 attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system.

  • --max-silent-time

    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.

  • --timeout

    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, Lix will still build the other inputs, but not the derivation itself. Without this option, Lix 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.

  • --fallback

    Whenever Lix 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, Lix 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).

  • --readonly-mode

    When this option is used, no attempt is made to open the Lix database. Most Lix operations do need database access, so those operations will fail.

    FIXME(Lix): sometimes you want --store dummy instead, because this option sometimes doesn't work. Document why this is.

  • --arg name value

    This option is accepted by nix-env, nix-instantiate, nix-shell and nix-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 value builtins.currentSystem for the system 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 value

    This 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 attrPath

    Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-shell only.) The attribute path attrPath is a sequence of attribute names separated by dots