Table of Contents
List of Figures
List of Tables
List of Examples
default.nix
)builder.sh
)all-packages-generic.nix
)remote-systems.conf
Nix is a system for the deployment of software. Software deployment is concerned with the creation, distribution, and management of software components (“packages”). Its main features are:
It helps you make sure that dependency specifications are complete. In general in a deployment system you have to specify for each component what its dependencies are, but there are no guarantees that this specification is complete. If you forget a dependency, then the component 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.
It is possible to have multiple versions or variants of a component installed at the same time. In contrast, in systems such as RPM different versions of the same package tend to install to the same location in the file system, so installing one version will remove the other. This is especially important if you want to use applications that have conflicting requirements on different versions of a component (e.g., application A requires version 1.0 of library X, while application B requires a non-backwards compatible version 1.1).
Users can have different “views” (“profiles” in Nix parlance) on the set of installed applications in a system. For instance, one user can have version 1.0 of some package visible, while another is using version 1.1, and a third doesn't use it at all.
It is possible to atomically upgrade software. I.e., there is no time window during an upgrade in which part of the old version and part of the new version are simultaneously visible (which might well cause the component to fail).
Likewise, it is possible to atomically roll back after an install, upgrade, or uninstall action. That is, in a fast (O(1)) operation the previous configuration of the system can be restored. This is because upgrade or uninstall actions don't actually remove components from the system.
Unused components can be garbage-collected automatically and safely: when you remove an application from a profile, its dependencies will be deleted by the garbage collector only if there are no other active applications using them.
Nix supports both source-based deployment models (where you distribute Nix expressions that tell Nix how to build software from source) and binary-based deployment models. The latter is more-or-less transparent: installation of components is always based on Nix expressions, but if the expressions have been built before and Nix knows that the resulting binaries are available somewhere, it will use those instead.
Nix is flexible in the deployment policies that it supports. There is a clear separation between the tools that implement basic Nix mechanisms (e.g., building Nix expressions), and the tools that implement various deployment policies. For instance, there is a concept of “Nix channels” that can be used to keep software installations up-to-date automatically from a network source. This is a policy that is implemented by a fairly short Perl script, which can be adapted easily to achieve similar policies.
Nix component builds aim to be “pure”; that is, unaffected by anything other than the declared dependencies. This means that if a component was built successfully once, it can be rebuilt again on another machine and the result will be the same. We cannot guarantee this (e.g., if the build depends on the time-of-day), but Nix (and the tools in the Nix Packages collection) takes special care to help achieve this.
Nix expressions (the things that tell Nix how to build components) are self-contained: they describe not just components but complete compositions. In other words, Nix expressions also describe how to build all the dependencies. This is in contrast to component specification languages like RPM spec files, which might say that a component X depends on some other component Y, but since it does not describe exactly what Y is, the result of building or running X might be different on different machines. Combined with purity, self-containedness ensures that a component that “works” on one machine also works on another, when deployed using Nix.
The Nix expression language makes it easy to describe variability in components (e.g., optional features or dependencies).
Nix is ideal for building build farms that do continuous builds of software from a version management system, since it can take care of building all the dependencies as well. Also, Nix only rebuilds components that have changed, so there are no unnecessary builds. In addition, Nix can transparently distribute build jobs over different machines, including different platforms.
Nix can be used not only for software deployment, but also for service deployment, such as the deployment of a complete web server with all its configuration files, static pages, software dependencies, and so on. Nix's advantages for software deployment also apply here: for instance, the ability trivially to have multiple configurations at the same time, or the ability to do rollbacks.
Nix can efficiently upgrade between different versions of a component through binary patching. If patches are available on a server, and you try to install a new version of some component, Nix will automatically apply a patch (or sequence of patches), if available, to transform the installed component into the new version.
This manual tells you how to install and use Nix and how to write Nix expressions for software not already in the Nix Packages collection. It also discusses some advanced topics, such as setting up a Nix-based build farm, and doing service deployment using Nix.
Some background information on Nix can be found in a number of papers. The ICSE 2004 paper Imposing a Memory Management Discipline on Software Deployment discusses the hashing mechanism used to ensure reliable dependency identification and non-interference between different versions and variants of packages. The LISA 2004 paper Nix: A Safe and Policy-Free System for Software Deployment gives a more general discussion of Nix from a system-administration perspective. The CBSE 2005 paper Efficient Upgrading in a Purely Functional Component Deployment Model is about transparent patch deployment in Nix. Finally, the SCM-12 paper Service Configuration Management shows how services (e.g., web servers) can be deployed and managed through Nix.
This chapter is for impatient people who don't like reading documentation. For more in-depth information you are kindly referred to the following chapters.
Download a source tarball or RPM from http://www.cs.uu.nl/groups/ST/Trace/Nix. Build source distributions using the regular sequence:
$ tar xvfj nix-version
.tar.bz2
$ ./configure
$ make
$ make install (as root)
This will install Nix in /nix
. You shouldn't
change the prefix if at all possible since that will make it
impossible to use our pre-built components. Alternatively, you could
grab an RPM if you're on an RPM-based system. You should also add
/nix/etc/profile.d/nix.sh
to your
~/.bashrc
(or some other login
file).
Subscribe to the Nix Packages channel.
$ nix-channel --add http://nix.cs.uu.nl/dist/nix/channels-v3/nixpkgs-unstable
Download the latest Nix expressions available in the channel.
$ nix-channel --update
Note that this in itself doesn't download any components, it just
downloads the Nix expressions that build them and stores them
somewhere (under ~/.nix-defexpr
, in case you're
curious). Also, it registers the fact that pre-built binaries are
available remotely.
See what installable components are currently available in the channel:
$ nix-env -qa
docbook-xml-4.2
firefox-1.0pre-PR-0.10.1
hello-2.1.1
libxslt-1.1.0
...
Install some components from the channel:
$ nix-env -i hello firefox ...
This should download the pre-built components; it should not build them locally (if it does, something went wrong).
Test that they work:
$ which hello
/home/eelco/.nix-profile/bin/hello
$ hello
Hello, world!
$ firefox
(read Slashdot or something)
Uninstall a package:
$ nix-env -e hello
To keep up-to-date with the channel, do:
$ nix-channel --update $ nix-env -u '*'
The latter command will upgrade each installed component for which there is a “newer” version (as determined by comparing the version numbers).
If you're unhappy with the result of a nix-env action (e.g., an upgraded component turned out not to work properly), you can go back:
$ nix-env --rollback
You should periodically run the Nix garbage collector to get rid of unused packages, since uninstalls or upgrades don't actually delete them:
$ nix-env --delete-generations old $ nix-store --gc
The first command deletes old “generations” of your profile (making rollbacks impossible, but also making the components in those old generations available for garbage collection), while the second command actually deletes them.
Table of Contents
The easiest way to obtain Nix is to download a source distribution. RPMs for Red Hat, SuSE, and Fedore Core are also available.
Alternatively, the most recent sources of Nix can be obtained
from its Subversion
repository. For example, the following command will check out
the latest revision into a directory called nix
:
$ svn checkout https://svn.cs.uu.nl:12443/repos/trace/nix/trunk nix
Likewise, specific releases can be obtained from the tags directory of the repository. If you don't have Subversion, you can also download an automatically generated compressed tar-file of the head revision of the trunk.
The following prerequisites only apply when you build from source. Binary releases (e.g., RPMs) have no prerequisites.
A fairly recent version of GCC/G++ is required. Version 2.95 and higher should work.
To build this manual and the man-pages you need the
xmllint and xsltproc programs,
which are part of the libxml2
and
libxslt
packages, respectively. You also need the
DocBook XSL
stylesheets and optionally the
DocBook XML 4.2 DTD. Note that these are only required if you
modify the manual sources or when you are building from the Subversion
repository.
To build the parser, very recent versions of Bison and Flex are required. (This is because Nix needs GLR support in Bison and reentrancy support in Flex.) For Bison, you need version 1.875c or higher (1.875 does not work), which can be obtained from the GNU FTP server. For Flex, you need version 2.5.31, which is available on SourceForge. Slightly older versions may also work, but ancient versions like the ubiquitous 2.5.4a won't. Note that these are only required if you modify the parser or when you are building from the Subversion repository.
Nix uses Sleepycat's Berkeley DB and CWI's ATerm library. These
are included in the Nix source distribution. If you build from the
Subversion repository, you must download them yourself and place them
in the externals/
directory. See
externals/Makefile.am
for the precise URLs of
these packages. Alternatively, if you already have them installed,
you can use configure's --with-bdb
and --with-aterm
options to point to their respective
locations. Note that Berkeley DB must be version
4.2; other versions may not have compatible database formats.
After unpacking or checking out the Nix sources, issue the following commands:
$ ./configure options...
$ make
$ make install
When building from the Subversion repository, these should be preceded by the command:
$ autoreconf -i
The installation path can be specified by passing the
--prefix=
to
configure. The default installation directory is
prefix
/nix
. You can change this to any location you
like. You must have write permission to the
prefix
path.
It is advisable not to change the installation prefix from its default, since doing so will in all likelihood make it impossible to use derivations built on other systems.
If you want to rebuilt the documentation, pass the full path to
the DocBook XML catalog file (docbook.cat
) and to
the DocBook XSL stylesheets using the
--with-docbook-catalog=
and
path
--with-docbook-xsl=
options.path
RPM packages of Nix can be downloaded from http://www.cs.uu.nl/groups/ST/Trace/Nix. These RPMs should
work for most fairly recent releases of SuSE and Red Hat Linux. They
have been known to work work on SuSE Linux 8.1 and 9.0, and Red Hat
9.0. In fact, it should work on any RPM-based Linux distribution
based on glibc
2.3 or later.
Once downloaded, the RPMs can be installed or upgraded using rpm -U. For example,
$ rpm -U nix-0.5pre664-1.i386.rpm
The RPMs install into the directory /nix
.
Nix can be uninstalled using rpm -e nix. After
this it will be necessary to manually remove the Nix store and other
auxiliary data:
$ rm -rf /nix/store $ rm -rf /nix/var
All Nix operations must be performed under the user ID that owns
the Nix store and database
(
and
prefix
/store
,
respectively). When installed from the RPM packages, these
directories are owned by prefix
/var/nix/dbroot
.
As a somewhat ad hoc hack, you can also
install the Nix binaries “setuid” so that a Nix store can
be shared among several users. To do this, configure Nix with the
--enable-setuid option. Nix will be installed as
owned by a user and group specified by the
--with-nix-user=
and
user
--with-nix-group=
options. E.g.,
group
$ ./configure --enable-setuid --with-nix-user=my_nix_user --with-nix-group=my_nix_group
The user and group default to nix
. You should make
sure that both the user and the group exist. Any “real”
users that you want to allow access should be added to the Nix
group.
A setuid installation should only by used if the users in the Nix group are mutually trusted, since any user in that group has the ability to change anything in the Nix store or database. For instance, they could install a trojan horse in executables used by other users.
On some platforms, the Nix binaries will be installed
as setuid root
. They drop root privileges
immediately after startup and switch to the Nix user. The reason for
this is that both the real and effective user must be set to the Nix
user, and POSIX has no system call to do this. This is not the case
on systems that have the setresuid()
system call
(such as Linux and FreeBSD), so on those systems the binaries are
simply owned by the Nix user.
To use Nix, some environment variables should be set. In
particular, PATH
should contain the directories
and
prefix
/bin~/.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
in your prefix
/etc/profile.d/nix.sh~/.bashrc
(or similar), like this:
source prefix
/etc/profile.d/nix.sh
Table of Contents
This chapter discusses how to do package management with Nix, i.e., how to obtain, install, upgrade, and erase components. This is the “user’s” perspective of the Nix system — people who want to create components should consult Chapter 5, Writing Nix Expressions.
The main command for package management is nix-env. You can use it to install, upgrade, and erase components, and to query what components are installed or are available for installation.
In Nix, 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 Nix how to build those components, including, if necessary, their dependencies. There is a collection of Nix expressions called the Nix Package collection that contains components ranging from basic development stuff such as GCC and Glibc, to end-user applications like Mozilla Firefox. (Nix is however not tied to the Nix Package collection; you could write your own Nix expressions based on it, or completely new ones.) You can download the latest version from http://nix.cs.uu.nl/dist/nix.
Assuming that you have downloaded and unpacked a release of Nix Packages, you can view the set of available components in the release:
$ nix-env -qaf nixpkgs-version
ant-blackdown-1.4.2
aterm-2.2
bash-3.0
binutils-2.15
bison-1.875d
blackdown-1.4.2
bzip2-1.0.2
...
where nixpkgs-
is
where you’ve unpacked the release.version
It is also possible to see the status of available components, i.e., whether they are installed into the user environment and/or present in the system:
$ nix-env -qasf nixpkgs-version
...
-PS bash-3.0
--S binutils-2.15
IPS bison-1.875d
...
The first character (I
) indicates whether the
component 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
component, which is Nix’s mechanism for doing binary deployment. It
just means that Nix know that it can fetch a pre-built component from
somewhere (typically a network server) instead of building it
locally.
So now that we have a set of Nix expressions we can build the
components contained in them. This is done using nix-env
-i
. For instance,
$ nix-env -f nixpkgs-version
-i subversion
will install the component called subversion
(which
is, of course, the Subversion version management
system).
When you do this for the first time, Nix will start building Subversion and all its dependencies. This will take quite a while — typically an hour or two on modern machines. Fortunately, there is a faster way (so do a Ctrl-C on that install operation!): you just need to tell Nix that pre-built binaries of all those components are available somewhere. This is done using the nix-pull command, which must be supplied with a URL containing a manifest describing what binaries are available. This URL should correspond to the Nix Packages release that you’re using. For instance, if you obtained a release from http://nix.cs.uu.nl/dist/nix/nixpkgs-0.6pre1554/, then you should do:
$ nix-pull http://nix.cs.uu.nl/dist/nix/nixpkgs-0.6pre1554/MANIFEST
If you then issue the installation command, it should start
downloading binaries from nix.cs.uu.nl
, instead of
building them from source. This might still take a while since all
dependencies must be downloaded, but on a reasonably fast connection
such as an DSL line it’s on the order of a few minutes.
Naturally, packages can also be uninstalled:
$ nix-env -e subversion
Upgrading to a new version is just as easy. If you have a new release of Nix Packages, you can do:
$ nix-env -f nixpkgs-version
-u 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 components for which there are newer versions:
$ nix-env -f nixpkgs-version
-u '*'
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 -u '*'
, you can do
$ nix-env ... -u '*' --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'
If you grow bored of specifying the Nix expressions using
-f
all the time, you can set a default
location:
$ nix-env -I nixpkgs-version
After this you can just say, for instance, nix-env -u
'*'
.[1]
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, components are stored in unique locations in the
Nix store (typically,
/nix/store
). For instance, a particular version
of the Subversion component 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[2] of
all inputs involved in building the component —
sources, dependencies, compiler flags, and so on. So if two
components differ in any way, they end up in different locations in
the file system, so they don’t interfere with each other. Figure 4.1, “User environments” shows a part of a typical Nix
store.
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 component 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 components. These are called
user environments and they are components
themselves (though automatically generated by
nix-env), so they too reside in the Nix store. For
instance, in Figure 4.1, “User environments” the user
environment /nix/store/5mq2jcn36ldl...-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 -i 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 -i subversion mozilla
on a set of Nix expressions that contained Mozilla 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 components doesn’t interfere in
any way with old components, 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
Actually, there is another level of indirection not shown in the
figure above. You generally wouldn’t have
/nix/var/nix/profiles/
in your some-profile
/binPATH
. 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 (see section Section 4.3, “Garbage collection”).
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 -p /nix/var/nix/profiles/other-profile -i subversion
This will not change the ~/.nix-profile symlink.
nix-env operations such as upgrades
(-u
) and uninstall (-e
) never
actually delete components from the system. All they do (as shown
above) is to create a new user environment that no longer contains
symlinks to the “deleted” components.
Of course, since disk space is not infinite, unused components should be removed at some point. You can do this by running the Nix garbage collector. It will remove from the Nix store any component not used (directly or indirectly) by any generation of any profile.
Note however that as long as old generations reference a component, 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
After removing appropriate old generations you can run the garbage collector as follows:
$ nix-store --gc
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.
The roots of the garbage collector are all store paths to which
there are symlinks in the directory
.
For instance, the following command makes the path
prefix
/nix/var/nix/gcroots/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
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.prefix
/nix/var/nix/gcroots
If you want to stay up to date with a set of packages, it’s not very convenient to manually download the latest set of Nix expressions for those packages, use nix-pull to register pre-built binaries (if available), and upgrade using nix-env. Fortunately, there’s a better way: Nix channels.
A Nix channel is just a URL that points to a place that contains a set of Nix expressions and a manifest. Using the command nix-channel you can automatically stay up to date with whatever is available at that URL.
You can “subscribe” to a channel using nix-channel --add, e.g.,
$ nix-channel --add http://nix.cs.uu.nl/dist/nix/channels-v3/nixpkgs-unstable
subscribes you to a channel that always contains that latest version
of the Nix Packages collection. (Instead of
nixpkgs-unstable
you could also subscribe to
nixpkgs-stable
, which should have a higher level of
stability, but right now is just outdated.) Subscribing really just
means that the URL is added to the file
~/.nix-channels
. Right now there is no command
to “unsubscribe”; you should just edit that file manually
and delete the offending URL.
To obtain the latest Nix expressions available in a channel, do
$ nix-channel --update
This downloads the Nix expressions in every channel (downloaded from
)
and registers any available pre-built binaries in every channel
(by nix-pulling
url
/nixexprs.tar.bz2
). It also
makes the union of each channel’s Nix expressions the default for
nix-env operations. Consequently, you can then say
url
/MANIFEST
$ nix-env -u '*'
to upgrade all components in your profile to the latest versions available in the subscribed channels.
[1] Setting a default using
-I
currently clashes with using Nix channels,
since nix-channel --update
calls nix-env
-I
to set the default to the Nix expressions it downloaded
from the channel, replacing whatever default you had
set.
[2] 160-bit truncations of SHA-256 hashes encoded in a base-32 notation, to be precise.
Table of Contents
This chapter shows you how to write Nix expressions, which are the things that tell Nix how to build components. It starts with a simple example (a Nix expression for GNU Hello), and then moves on to a more in-depth look at the Nix expression language.
This section shows how to add and test the GNU Hello package to the Nix Packages collection. Hello is a program that prints out the text “Hello, world!”.
To add a component to the Nix Packages collection, you generally need to do three things:
Write a Nix expression for the component. This is a file that describes all the inputs involved in building the component, such as dependencies (other components required by the component), sources, and so on.
Write a builder. This is a shell script[3] that actually builds the component from the inputs.
Add the component to the file
pkgs/system/all-packages-generic.nix
. The Nix
expression written in the first step is a
function; it requires other components in order
to build it. In this step you put it all together, i.e., you call
the function with the right arguments to build the actual
component.
Example 5.1. Nix expression for GNU Hello
(default.nix
)
{stdenv, fetchurl, perl}:stdenv.mkDerivation {
name = "hello-2.1.1";
builder = ./builder.sh;
src = fetchurl {
url = ftp://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz; md5 = "70c9ccf9fac07f762c24f2df2290784d"; }; inherit perl;
}
Example 5.1, “Nix expression for GNU Hello
(default.nix
)” shows a Nix expression for GNU
Hello. It's actually already in the Nix Packages collection in
pkgs/applications/misc/hello/ex-1/default.nix
.
It is customary to place each package in a separate directory and call
the single Nix expression in that directory
default.nix
. The file has the following elements
(referenced from the figure by number):
![]() | This states that the expression is a
function that expects to be called with three
arguments: Nix functions generally have the form |
![]() | So we have to build a component. Building something from
other stuff is called a derivation in Nix (as
opposed to sources, which are built by humans instead of
computers). We perform a derivation by calling
|
![]() | The attribute |
![]() | The attribute |
![]() | The builder has to know what the sources of the component
are. Here, the attribute Instead of |
![]() | Since the derivation requires Perl, we have to pass the
value of the perl = perl;
will do the trick: it binds an attribute |
Example 5.2. Build script for GNU Hello
(builder.sh
)
. $stdenv/setupPATH=$perl/bin:$PATH
tar xvfz $src
cd hello-* ./configure --prefix=$out
make
make install
Example 5.2, “Build script for GNU Hello
(builder.sh
)” shows the builder referenced
from Hello's Nix expression (stored in
pkgs/applications/misc/hello/ex-1/builder.sh
).
The builder can actually be made a lot shorter by using the
generic builder functions provided by
stdenv
, but here we write out the build steps to
elucidate what a builder does. It performs the following
steps:
![]() | When Nix runs a builder, it initially completely clears the
environment (except for the attributes declared in the
derivation). For instance, the So the first step is to set up the environment. This is
done by calling the |
![]() | Since Hello needs Perl, we have to make sure that Perl is in
the |
![]() | Now we have to unpack the sources. The
The whole build is performed in a temporary directory
created in |
![]() | GNU Hello is a typical Autoconf-based package, so we first
have to run its |
![]() | Finally we build Hello ( |
If you are wondering about the absence of error checking on the
result of various commands called in the builder: this is because the
shell script is evaluated with Bash's -e
option,
which causes the script to be aborted if any command fails without an
error check.
Example 5.3. Composing GNU Hello
(all-packages-generic.nix
)
... rec {hello = (import ../applications/misc/hello/ex-1
) {
inherit fetchurl stdenv perl; }; perl = (import ../development/interpreters/perl) {
inherit fetchurl stdenv; }; fetchurl = (import ../build-support/fetchurl) { inherit stdenv; ... }; stdenv = ...; }
The Nix expression in Example 5.1, “Nix expression for GNU Hello
(default.nix
)” is a
function; it is missing some arguments that have to be filled in
somewhere. In the Nix Packages collection this is done in the file
pkgs/system/all-packages-generic.nix
, where all
Nix expressions for components are imported and called with the
appropriate arguments. Example 5.3, “Composing GNU Hello
(all-packages-generic.nix
)” shows
some fragments of
all-packages-generic.nix
.
![]() | This file defines a set of attributes, all of which are concrete derivations (i.e., not functions). In fact, we define a mutually recursive set of attributes. That is, the attributes can refer to each other. This is precisely what we want since we want to “plug” the various components into each other. |
![]() | Here we import the Nix expression for
GNU Hello. The import operation just loads and returns the
specified Nix expression. In fact, we could just have put the
contents of Example 5.1, “Nix expression for GNU Hello
( Note that we refer to
|
![]() | This is where the actual composition takes place. Here we
call the function imported from
The result of this function call is an actual derivation
that can be built by Nix (since when we fill in the arguments of
the function, what we get is its body, which is the call to
|
![]() | Likewise, we have to instantiate Perl,
|
You can now try to build Hello. The simplest way to do that is by using nix-env:
$ nix-env -f pkgs/system/i686-linux.nix -i hello
installing `hello-2.1.1'
building path `/nix/store/632d2b22514dcebe704887c3da15448d-hello-2.1.1'
hello-2.1.1/
hello-2.1.1/intl/
hello-2.1.1/intl/ChangeLog
...
This will build Hello and install it into your profile. The file
i686-linux
is just a simple Nix expression that
imports all-packages-generic.nix
and instantiates
it for Linux on the x86 platform.
Note that the hello
argument here refers to
the symbolic name given to the Hello derivation (the
name
attribute in Example 5.1, “Nix expression for GNU Hello
(default.nix
)”),
not the hello
attribute in
all-packages-generic.nix
.
nix-env simply walks through all derivations
defined in the latter file, looking for one with a
name
attribute matching the command-line
argument.
You can test whether it works:
$ hello Hello, world!
Generally, however, using nix-env is not the best way to test components, since you may not want to install them into your profile right away (they might not work properly, after all). A better way is to write a short file containing the following:
(import pkgs/system/i686-linux.nix).hello
Call it test.nix
. You can then build it without
installing it using the command nix-build:
$ nix-build ./test.nix ... /nix/store/632d2b22514dcebe704887c3da15448d-hello-2.1.1
nix-build will build the derivation and print the
output path. It also creates a symlink to the output path called
result
in the current directory. This is
convenient for testing the component:
$ ./result/bin/hello Hello, world!
Nix has a transactional semantics. Once a build finishes
successfully, Nix makes a note of this in its database: it registers
that the path denoted by out
is now
“valid”. If you try to build the derivation again, Nix
will see that the path is already valid and finish immediately. If a
build fails, either because it returns a non-zero exit code, because
Nix or the builder are killed, or because the machine crashes, then
the output path will not be registered as valid. If you try to build
the derivation again, Nix will remove the output path if it exists
(e.g., because the builder died half-way through make
install
) and try again. Note that there is no
“negative caching”: Nix doesn't remember that a build
failed, and so a failed build can always be repeated. This is because
Nix cannot distinguish between permanent failures (e.g., a compiler
error due to a syntax error in the source) and transient failures
(e.g., a disk full condition).
Nix also performs locking. If you run multiple Nix builds simultaneously, and they try to build the same derivation, the first Nix instance that gets there will perform the build, while the others block (or perform other derivations if available) until the build finishes. So it is always safe to run multiple instances of Nix in parallel (contrary to, say, make).
If you have a system with multiple CPUs, you may want to have
Nix build different derivations in parallel (insofar as possible).
Just pass the option -j
,
where N
N
is the maximum number of jobs to be
run in parallel. Typically this should be the number of CPUs.
Recall from Example 5.2, “Build script for GNU Hello
(builder.sh
)” that the builder
looked something like this:
PATH=$perl/bin:$PATH tar xvfz $src cd hello-* ./configure --prefix=$out make make install
The builders for almost all Unix packages look like this — set up some environment variables, unpack the sources, configure, build, and install. For this reason the standard environment provides some Bash functions that automate the build process. A builder using the generic build facilities in shown in Example 5.4, “Build script using the generic build functions”.
Example 5.4. Build script using the generic build functions
buildInputs="$perl". $stdenv/setup
genericBuild
![]() | The |
![]() | The function |
![]() | The final step calls the shell function
|
Discerning readers will note that the
buildInputs
could just as well have been set in the Nix
expression, like this:
buildInputs = [perl];
The perl
attribute can then be removed, and the
builder becomes even shorter:
. $stdenv/setup genericBuild
In fact, mkDerivation
provides a default builder
that looks exactly like that, so it is actually possible to omit the
builder for Hello entirely.
The Nix expression language is a pure, lazy, functional language. Purity means that operations in the language don't have side-effects (for instance, there is no variable assignment). Laziness means that arguments to functions are evaluated only when they are needed. Functional means that functions are “normal” values that can be passed around and manipulated in interesting ways. The language is not a full-featured, general purpose language. It's main job is to describe components, compositions of components, and the variability within components.
This section presents the various features of the language.
Nix has the following basic datatypes:
Strings, enclosed between
double quotes, e.g., "foo bar"
.
Integers, e.g.,
123
.
URIs as defined in appendix B
of RFC
2396, e.g.,
https://svn.cs.uu.nl:12443/dist/trace/trace-nix-trunk.tar.bz2
.
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[5]. If the filename 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 absolutised path is
/foo/xyzzy/fnord.nix
.
Booleans with values
true
and
false
.
Lists are formed by enclosing a whitespace-separated list of values between square bracktes. 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 an attribute set.
Attribute sets are really the core of the language, since ultimately it's all about creating derivations, which are really just sets of attributes to be passed to build scripts.
Attribute sets are just a list of name/value pairs enclosed in curly brackets, where each value is an arbitrary expression terminated by a semicolon. For example:
{ x = 123; text = "Hello"; y = f { bla = 456; }; }
This defines an attribute set with attributes named
x
, test
, y
.
The order of the attributes is irrelevant. An attribute name may only
occur once.
Attributes can be selected from an attribute set using the
.
operator. For instance,
{ a = "Foo"; b = "Bar"; }.a
evaluates to "Foo"
.
Recursive attribute sets are just normal attribute sets, but the attributes can refer to each other. For example,
rec { x = y; y = 123; }.x
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) attribute set, attributes are not
added to the lexical scope; in a recursive set, they are.
Recursive attribute sets of course introduce the danger of infinite recursion. For example,
rec { x = y; y = x; }.x
does not terminate[6].
A let
expression is a simple short-hand for a
rec
expression followed by an attribute selection:
let {
translates
to attrs
}rec {
.attrs
}.body
For instance,
let { x = "foo"; y = "bar"; body = x + y; }
is equivalent to
rec { x = "foo"; y = "bar"; body = x + y; }.body
and evaluates to "foobar"
.
When defining an attribute set 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. For instance,
let { x = 123; body = { inherit x; y = 456; }; }
evaluates to {x = 123; y = 456;}
. (Note that 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. For instance, in this fragment
from all-packages-generic.nix
,
graphviz = (import ../tools/graphics/graphviz) { inherit fetchurl stdenv libpng libjpeg expat x11 yacc; inherit (xlibs) libXaw; }; xlibs = { libX11 = ...; libXaw = ...; ... } libpng = ...; libjpg = ...; ...
the attribute 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
xlibs
(X11 client-side libraries) attribute
set.
Functions have the following form:
{params
}:body
This defines a function that must be called with an attribute set
containing the attributes listed in params
,
which is a comma-separated list of attribute names. Optionally, for
each parameter a default value may be specified
by writing
, where
param
?
e
e
is an arbitrary expression. If a
parameter has a default, the corresponding attribute may be omitted in
function calls.
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; body = concat {x = "foo"; y = "bar";}; }
It is also possible to define a function that takes a single argument and that does not need to be called with an attribute set as argument. The syntax is
var
:body
where var
is the name of the argument. It
is not possible to define a default. Example:
let { negate = x: !x; concat = x: y: x + y; body = if negate true then concat "foo" "bar" else ""; }
Note that concat
is a function that takes one
arguments 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"]
.
Conditionals look like this:
ife1
thene2
elsee3
where e1
is an expression that should
evaluate to a boolean value (true
or
false
).
Assertions are generally used to check that certain requirements on or between features and dependencies hold. They look like this:
asserte1
;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.
Example 5.5. Nix expression for Subversion
{ 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;
... }
Example 5.5, “Nix expression for Subversion” show how assertions are used in the Nix expression for Subversion.
A with expression,
withe1
;e2
introduces the attribute set e1
into the
lexical scope of the expression e2
. For
instance,
let { as = {x = "foo"; y = "bar";}; body = 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 rec
-expression.
Table 5.1, “Operators” lists the operators in the Nix expression language, in order of precedence (from strongest to weakest binding).
Table 5.1. Operators
Syntax | Associativity | Description |
---|---|---|
e1 ~ e2 | none | Construct a reference to a subpath of a derivation.
E.g., hello ~ "/bin/sh" refers to the
/bin/sh path within the Hello derivation.
Useful in specifying derivation attributes. |
e ?
id | none | Test whether attribute set e
contains an attribute named
id . |
e1 ++ e2 | right | List concatenation. |
e1 + e2 | left | String or path concatenation. |
! e | left | Boolean negation. |
e1 //
e2 | right | Return an attribute set consisting of the attributes in
e1 and
e2 (with the latter taking
precedence over the former in case of equally named attributes). |
e1 ==
e2 | none | Equality. |
e1 !=
e2 | none | Inequality. |
e1 &&
e2 | left | Logical AND. |
e1 ||
e2 | left | Logical OR. |
e1 ->
e2 | none | Logical implication (equivalent to
! ). |
The most important built-in function is
derivation
, which is used to describe a
single derivation (a build action). It takes as input an attribute
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 platform identifier, such as "i686-linux"
or
"powerpc-darwin"
[7] The build
can only be performed on a machine and operating system matching the
platform identifier. (Nix can automatically forward builds for
other platforms by forwarding them to other machines; see Section 6.2, “Setting up distributed builds”.)
There must be an attribute named
name
whose value must be a string. This is used
as a symbolic name for the component by nix-env,
and it is appended to the hash in the output path 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, URIs, and integers 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; the output path is put in the environment variable.
Lists of the previous types are also allowed. They are simply concatenated, separated by spaces.
The optional argument args
specifies command-line arguments to be passed to the builder. It
should be a list.
(Note that mkDerivation
in the 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 Section 5.3, “The standard environment”.)
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
).
out
is set to point to the output
path of the derivation, which is a subdirectory of the Nix store.
The output path is a concatenation of the cryptographic hash of
all build inputs, and the name
attribute.
If the output path already exists, it is removed. Also, locks are acquired to prevent multiple Nix instances from performing the same build at the same time.
A log of the combined standard output and error is
written to /nix/var/log/nix
.
The builder is executed with the arguments specified
by the attribute args
. If it exits with exit
code 0, it is considered to have succeeded.
The temporary directory is removed (unless the
-K
option was specified).
If the build was successful, Nix scans the output for references to the paths of the inputs. These so-called retained dependencies could be used when the output of the derivation is used (e.g., when it's executed or used as input to another derivation), so if we deploy the derivation, we should copy the retained dependencies as well. The scan is performed by looking for the hash parts of file names of the inputs.
After the build, Nix sets the last-modified
timestamp on all files in the build result to 0 (00:00:00 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
Nix. This is because the Nix archives used in deployment have no
concept of ownership information, and because it makes the build
result dependent on the user performing the build.
The standard build environment in the Nix Packages collection provides a basic environment for building Unix packages. It consists of the following components:
The GNU C Compiler, configured with C and C++
support. On Linux, the compiler has been patched to provide greater
“purity” assurance. For instance, the compiler doesn't
search in locations such as /usr/include
. In
fact, attempts to add such directories through the
-I
flag are filtered out. Likewise, the linker
(from GNU binutils) doesn't search in standard locations such as
/usr/lib
. Programs built on Linux are linked
against a GNU C Library that likewise doesn't search in the default
system locations.
GNU coreutils (contains a few dozen standard Unix commands).
GNU findutils (contains find).
GNU diffutils (contains diff, cmp).
GNU sed.
GNU grep.
GNU awk.
GNU tar.
gzip and bzip2.
GNU Make. It has been patched to provide “nested” output that can be fed into the log2xml command and log2html stylesheet to create a structured, readable output of the build steps performed by Make.
Bash. This is the shell used for all builders in the Nix Packages collection. Not using /bin/sh removes a large source of portability problems.
Patch.
The standard environment is used by passing it as an input
called stdenv
to the derivation, and then doing
. $stdenv/setup
at the top of the builder.
Apart from adding the aforementioned commands to the
PATH
, setup
also does the
following:
All input components specified in the
buildInputs
environment variable have their
/bin
subdirectory added to PATH
,
their /include
subdirectory added to the C/C++
header file search path, and their /lib
subdirectory added to the linker search path. This can be extended.
For instance, when the pkgconfig component is
used, the subdirectory /lib/pkgconfig
of each
input is added to the PKG_CONFIG_PATH
environment
variable.
The environment variable
NIX_CFLAGS_STRIP
is set so that the compiler strips
debug information from object files. This can be disabled by
setting NIX_STRIP_DEBUG
to
0
.
The setup
script also exports a function
called genericBuild
that knows how to build
typical Autoconf-style components. It can be customised to perform
builds for any type of component. It is advisable to use
genericBuild
since it provides facilities that
are almost always useful such as unpacking of sources, patching of
sources, nested logging, etc.
The operation of the generic builder can be modified in many
places by setting certain variables. These hook
variables are typically set to the name of some shell
function defined by you. For instance, to perform some additional
steps after make install you would set the
postInstall
variable:
postInstall=myPostInstall myPostInstall() { mkdir $out/share/extra cp extrafiles/* $out/share/extra }
The generic builder has a number of phases, each of which can be override in its entirety by setting the indicated variable. The phases are:
unpackPhase
unpacks the source files
listed in the src
environment variable to the
current directory. It supports tar
files,
optionally compressed with gzip or
bzip2; Zip files (but note that the
unzip command is not a part of the standard
environment; you should add it as a build input yourself); and
unpacked source trees (i.e., directories; they are copied
verbatim). You can add support for other file types by setting
the findUnpacker
hook. This hook should set
the variable unpackCmd
to contain the command
to be executed to unpack the file.
After unpacking all source files,
unpackPhase
changes the current directory to
the directory created by unpacking the sources. If there are
multiple source directories, you should set
sourceRoot
to the name of the intended
directory.
It also calls the hook postUnpack
after
unpacking.
patchPhase
calls the
patch command with the -p1
option for each patch file listed in the patches
variable.
configurePhase
runs the script called
configure
in the current directory with a
--prefix
set to the output path. You can add
additional flags through the configureFlags
variable. If configure
does not exist,
nothing happens.
Before and after running configure
, the
hooks preConfigure
and
postConfigure
are called, respectively.
buildPhase
calls
make. You can set flags for
make through the makeFlags
variable.
Before and after running make, the hooks
preBuild
and postBuild
are
called, respectively.
checkPhase
calls make
check, but only if the doCheck
variable
is set to 1
. Additional flags can be set through
the checkFlags
variable.
installPhase
calls make
install. Additional flags can be set through the
installFlags
variable. It also strips any
static libraries in the output path of debug information unless
dontStrip
is set to
1
.
Before and after running make install,
the hooks preInstall
and
postInstall
are called, respectively.
distPhase
calls make
dist, but only if the doDist
variable
is set to 1
. Additional flags can be set
through the distFlags
variable. The resulting
tarball is copied to the /tarballs
subdirectory of the output path.
Before and after running make dist, the
hooks preDist
and postDist
are called, respectively.
You can change the order in which phases are executed, or add
new phases, by setting the phases
variable. The
default is patchPhase configurePhase buildPhase checkPhase
installPhase distPhase
.
At the beginning of each phase, the set of all shell variables
is written to the file env-vars
at the top-level
build directory. This is useful for debugging: it allows you to
recreate the environment in which a build was performed. For
instance, if a build fails, then assuming you used the
-K
flag, you can go to the output directory and
“switch” to the environment of the builder:
$ nix-build -K ./foo.nix ... fails, keeping build directory `/tmp/nix-1234-0' $ cd /tmp/nix-1234-0 $ source env-vars (edit some files...) $ make (execution continues with the same GCC, make, etc.)
The definitive, up-to-date documentation of the generic builder
is the source itself, which resides in
pkgs/stdenv/generic/setup.sh
.
[3] In fact, it can be written in any language, but typically it's a bash shell script.
[4] Actually, it's initialised to
/path-not-set
to prevent Bash from setting it
to a default value.
[5] It's parsed as an expression that selects the
attribute sh
from the variable
builder
.
[6] Actually, Nix detects infinite recursion in this case and aborts (“infinite recursion encountered”).
[7] To figure out
your platform identifier, look at the line “Checking for the
canonical Nix system name” in the output of Nix's
configure
script.
Table of Contents
This chapter provides some sketchy information on how to set up a Nix-based build farm. Nix is particularly suited as a basis for a build farm, since:
Nix supports distributed builds: a local Nix
installation can forward Nix builds to other machines over the
network. This allows multiple builds to be performed in parallel
(thus improving performance), but more in importantly, it allows Nix
to perform multi-platform builds in a semi-transparent way. For
instance, if you perform a build for a
powerpc-darwin
on an
i686-linux
machine, Nix can automatically forward
the build to a powerpc-darwin
machine, if
available.
The Nix expression language is ideal for describing build jobs, plus all their dependencies. For instance, if your package has some dependency, you don't have to manually install it on all the machines in the build farm; they will be built automatically.
Proper release management requires that builds (if deployed) are traceable: it should be possible to figure out from exactly what sources they were built, in what configuration, etc.; and it should be possible to reproduce the build, if necessary. Nix makes this possible since Nix's hashing scheme uniquely identifies builds, and Nix expressions are self-contained.
Nix will only rebuild things that have actually changed. For instance, if the sources of a component haven't changed between runs of the build farm, the component won't be rebuild (unless it was garbage-collected). Also, dependencies typically don't change very often, so they only need to be built once.
The results of a Nix build farm can be made available through a channel, so successful builds can be deployed to users immediately.
TODO
The sources of the Nix build farm are at https://svn.cs.uu.nl:12443/repos/trace/release/trunk.
You can enable distributed builds by setting the environment
variable NIX_BUILD_HOOK
to point to a program that Nix
will call whenever it wants to build a derivation. The build hook
(typically a shell or Perl script) can decline the build, in which Nix
will perform it in the usual way if possible, or it can accept it, in
which case it is responsible for somehow getting the inputs of the
build to another machine, doing the build there, and getting the
results back. The details of the build hook protocol are described in
the documentation of the NIX_BUILD_HOOK
variable.
Example 6.1. Remote machine configuration:
remote-systems.conf
nix@mcflurry.labs.cs.uu.nl powerpc-darwin /home/nix/.ssh/id_quarterpounder_auto 2 nix@scratchy.labs.cs.uu.nl i686-linux /home/nix/.ssh/id_scratchy_auto 1
An example build hook can be found in the Nix build farm
sources: https://svn.cs.uu.nl:12443/repos/trace/release/trunk/common/distributed/build-remote.pl. It should be suitable for most purposes, with maybe some minor
adjustments. It uses ssh and
rsync to copy the build inputs and outputs and
perform the remote build. You should define a list of available build
machines and set the environment variable
REMOTE_SYSTEMS
to point to it. An example
configuration is shown in Example 6.1, “Remote machine configuration:
remote-systems.conf
”. Each
line in the file specifies a machine, with the following bits of
information:
The name of the remote machine, with optionally the
user under which the remote build should be performed. This is
actually passed as an argument to ssh, so it can
be an alias defined in your
~/.ssh/config
.
The Nix platform type identifier, such as
powerpc-darwin
.
The SSH private key to be used to log in to the remote machine. Since builds should be non-interactive, this key should not have a passphrase!
The maximum “load” of the remote
machine. This is just the maximum number of jobs that
build-remote.pl
will execute in parallel on the
machine. Typically this should be equal to the number of
CPUs.
You should also set up the environment variable
CURRENT_LOAD
to point at a file that
build-remote.pl
uses to remember how many jobs it
is currently executing remotely. It doesn't look at the actual load
on the remote machine, so if you have multiple instances of Nix
running, they should use the same CURRENT_LOAD
file[8]. Maybe in the future
build-remote.pl
will look at the actual remote
load. The load file should exist, so you should just create it as an
empty file initially.
Table of Contents
Most Nix commands accept the following command-line options:
--help
Prints out a summary of the command syntax and exits.
--version
Prints out the Nix version number on standard output and exits.
--verbose
, -v
Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined; any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. Currently, the following verbosity levels exist:
“Errors only”: only print messages explaining why the Nix invocation failed.
“Informational”: print useful messages about what Nix is doing. This is the default.
“Talkative”: print more informational messages.
“Chatty”: print even more informational messages.
“Debug”: print debug information.
“Vomit”: print vast amounts of debug information.
--no-build-output
, -Q
By default, output written by builders to standard
output and standard error is echoed to the Nix command's standard
error. This option suppresses this behaviour. Note that the
builder's standard output and error are always written to a log file
in
.prefix
/nix/var/log/nix
--max-jobs
, -j
Sets the maximum number of build jobs that Nix will perform in parallel to the specified number. The default is 1. A higher value is useful on SMP systems or to exploit I/O latency.
--keep-going
, -k
Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
--keep-failed
, -K
Specifies that in case of a build failure, the
temporary directory (usually in /tmp
) in which
the build takes place should not be deleted. The path of the build
directory is printed as an informational message.
--fallback
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on nstallation 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 Nix database. Most Nix operations do need database access, so those operations will fail.
--log-type
type
This option determines how the output written to standard
error is formatted. Nix’s diagnostic messages are typically
nested. For instance, when tracing Nix
expression evaluation (nix-env -vvvvv, messages
from subexpressions are nested inside their parent expressions. Nix
builder output is also often nested. For instance, the Nix Packages
generic builder nests the various build tasks (unpack, configure,
compile, etc.), and the GNU Make in stdenv-linux
has been patched to provide nesting for recursive Make
invocations.
type
can be one of the
following:
pretty
Pretty-print the output, indicating different nesting levels using spaces. This is the default.
escapes
Indicate nesting using escape codes that can be interpreted by the log2xml tool in the Nix source distribution. The resulting XML file can be fed into the log2html.xsl stylesheet to create an HTML file that can be browsed interactively, using Javascript to expand and collapse parts of the output.
flat
Remove all nesting.
Most Nix commands interpret the following environment variables:
NIX_ROOT
If NIX_ROOT
is set, the Nix command
will on startup perform a chroot()
to the
specified directory. This is useful in certain bootstrapping
situations (e.g., when installing a Nix installation onto a hard
disk from CD-ROM).
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 Nix static data
directory (default
).prefix
/share
NIX_LOG_DIR
Overrides the location of the Nix log directory
(default
).prefix
/log/nix
NIX_STATE_DIR
Overrides the location of the Nix state directory
(default
).prefix
/var/nix
NIX_DB_DIR
Overrides the location of the Nix database (default
, i.e.,
$NIX_STATE_DIR
/db
).prefix
/var/nix/db
NIX_CONF_DIR
Overrides the location of the Nix configuration
directory (default
).prefix
/etc/nix
NIX_LOG_TYPE
Equivalent to the --log-type
option.
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_BUILD_HOOK
Specifies the location of the build hook, which is a program (typically some script) that Nix will call whenever it wants to build a derivation. This is used to implement distributed builds (see Section 6.2, “Setting up distributed builds”). The protocol by which the calling Nix process and the build hook communicate is as follows.
The build hook is called with the following command-line arguments:
A boolean value 0
or
1
specifying whether Nix can locally execute
more builds, as per the --max-jobs
option.
The purpose of this argument is to allow the hook to not have to
maintain bookkeeping for the local machine.
The Nix platform identifier for the local machine
(e.g., i686-linux
).
The Nix platform identifier for the derivation,
i.e., its system
attribute.
The store path of the derivation.
On the basis of this information, and whatever persistent
state the build hook keeps about other machines and their current
load, it has to decide what to do with the build. It should print
out on file descriptor 3 one of the following responses (terminated
by a newline, "\n"
):
decline
The build hook is not willing or able to perform the build; the calling Nix process should do the build itself, if possible.
postpone
The build hook cannot perform the build now, but can do so in the future (e.g., because all available build slots on remote machines are in use). The calling Nix process should postpone this build until at least one currently running build has terminated.
accept
The build hook has accepted the build.
If the build hook accepts the build, it is possible that it is no longer necessary to do the build because some other process has performed the build in the meantime. To prevent races, the hook must read from file descriptor 4 a single line that tells it whether to continue:
cancel
The build has already been done, so the hook should exit.
okay
The hook should proceed with the build. At this point, the calling Nix process has acquired locks on the output path, so no other Nix process will perform the build.
If the hook has been told to proceed, Nix will store in the hook’s current directory a number of text files that contain information about the derivation:
inputs
The set of store paths that are inputs to the build process (one per line). These have to be copied to the remote machine (in addition to the store derivation itself).
outputs
The set of store paths that are outputs of the derivation (one per line). These have to be copied from the remote machine if the build succeeds.
references
The reference graph of the inputs, in the format accepted by the command nix-store --register-validity. It is necessary to run this command on the remote machine after copying the inputs to inform Nix on the remote machine that the inputs are valid paths.
The hook should copy the inputs to the remote machine,
register the validity of the inputs, perform the remote build, and
copy the outputs back to the local machine. An exit code other than
0
indicates that the hook has failed.
A number of persistent settings of Nix are stored in the file
.
This file is a list of prefix
/etc/nix/nix.conf
pairs, one per line.
Comments start with a name
=
value
#
character. An example
configuration file is shown in Example A.1, “Nix configuration file”.
Example A.1. Nix configuration file
gc-keep-outputs = true # Nice for developers gc-keep-derivations = true # Idem env-keep-derivations = false
The following variables are currently available:
gc-keep-outputs
If true
, the garbage collector
will keep the outputs of non-garbage derivations. If
false
(default), outputs will be deleted unless
they are GC roots themselves (or reachable from other roots).
In general, outputs must be registered as roots separately.
However, even if the output of a derivation is registered as a
root, the collector will still delete store paths that are used
only at build time (e.g., the C compiler, or source tarballs
downloaded from the network). To prevent it from doing so, set
this option to true
.
gc-keep-derivations
If true
(default), the garbage
collector will keep the derivations from which non-garbage store
paths were built. If false
, they will be
deleted unless explicitly registered as a root (or reachable from
other roots).
Keeping derivation around is useful for querying and
traceability (e.g., it allows you to ask with what dependencies or
options a store path was built), so by default this option is on.
Turn it off to safe a bit of disk space (or a lot if
gc-keep-outputs
is also turned on).
env-keep-derivations
If false
(default), derivations
are not stored in Nix user environments. That is, the derivation
any build-time-only dependencies may be garbage-collected.
If true
, when you add a Nix derivation to
a user environment, the path of the derivation is stored in the
user environment. Thus, the derivation will not be
garbage-collected until the user environment generation is deleted
(nix-env --delete-generations). To prevent
build-time-only dependencies from being collected, you should also
turn on gc-keep-outputs
.
The difference between this option and
gc-keep-derivations
is that this one is
“sticky”: it applies to any user environment created while this
option was enabled, while gc-keep-derivations
only applies at the moment the garbage collector is
run.
nix-env — manipulate or query Nix user environments
nix-env
[--help
] [--version
] [--verbose
...] [-v
...] [--no-build-output
] [-Q
] [
{ --max-jobs
| -j
}
number
] [--keep-going
] [-k
] [--keep-failed
] [-K
] [--fallback
] [--readonly-mode
] [--log-type
type
] [
{ --file
| -f
}
path
] [
{ --profile
| -p
}
path
] [--preserve-installed
] [
--system-filter
system
] [--dry-run
] [--from-expression
] [-E
] [--from-profile
path
] operation
[options
...] [arguments
...]
The command nix-env is used to manipulate Nix user environments. User environments are sets of software components 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. These are documented below.
This section lists the options that are common to all operations. These options are allowed for every subcommand, though they may not always have an effect. See also Section A.1, “Common options”.
--file
, -f
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
.
--profile
, -p
Specifies the profile to be used by those
operations that operate on a profile (designated below as the
active profile). A profile is sequence of
user environments called generations, one of
which is the current generation. The default
profile is the target of the symbolic link
~/.nix-profile
(see below).
--dry-run
For the --install
,
--upgrade
, --uninstall
,
--switch-generation
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.
--preserve-installed
By default, when you install a derivation with the
--install
operation, it will replace previously
installed versions with the same derivation name (regardless of
the version number). This option causes those previously
installed versions to be kept in the new generation of the
profile. Note that this will generally cause conflicts in the
creation of the user environment (since multiple versions of a
package typically contain the same programs).
--system-filter
system
By default, operations such as --query
--available
only include derivations matching the current
platform. This option allows you to use derivations for the
specified platform system
. The special
value *
causes derivations for any platform to
be included.
~/.nix-defexpr
The default Nix expression used by the
--install
, --upgrade
, and
--query --available
operations to obtain
derivations. It is generally a symbolic link to some other
location set using the --import
operation. The
--file
option may be used to override this
default.
~/.nix-profile
A symbolic link to the user's current profile. By
default, this symlink points to
.
The prefix
/var/nix/profiles/defaultPATH
environment variable should include
~/.nix-profile/bin
for the user environment
to be visible to the user.
--install
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 --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 a 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.
--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.
To install a specific version of gcc from the active Nix expression:
$ nix-env --install gcc-3.3.2 installing `gcc-3.3.2' uninstalling `gcc-3.1'
Note the 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 -f ~/foo.nix -i '*'
To copy the store path with symbolic name gcc
from another profile:
$ nix-env -i --from-profile /nix/var/nix/profiles/foo -i gcc
To install a specific store derivation (typically created by nix-instantiate):
$ nix-env -i /nix/store/fibjb1bfbpm5mrsxc4mh2d8n37sxh91i-gcc-3.4.3.drv
To install a specific output path:
$ nix-env -i /nix/store/y3cgx0xj1p4iv9x0pnnmdhr8iyg741vk-gcc-3.4.3
To install from a Nix expression specified on the command-line:
$ nix-env -f ./foo.nix -i -E \ '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
attribute set returned by calling the function defined in
./foo.nix
.
--upgrade
The upgrade operation creates a new user environment, based on
the current generation of the active profile, in which all store paths
are replaced for which there are newer versions in the set of paths
described by args
. Paths for which there
are no newer versions are left untouched; this is not an error. It is
also not an error if an element of args
matches no installed derivations.
For a description of how args
is
mapped to a set of store paths, see --install
. If
args
describes multiple store paths with
the same symbolic name, only the one with the highest version is
installed.
--lt
Only upgrade a derivation to newer versions. This is the default.
--leq
In addition to upgrading to newer versions, also “upgrade” to derivations that have the same version. Version are not a unique identification of a derivation, so there may be many derivations that have the same version. This flag may be useful to force “synchronisation” between the installed and available derivations.
--always
In addition to upgrading to newer versions, also “upgrade” to derivations that have the same or a lower version. I.e., derivations may actually be downgraded depending on what is available in the active Nix expression.
$ nix-env --upgrade gcc upgrading `gcc-3.3.1' to `gcc-3.4' $ nix-env -u gcc-3.3.2 --always (switch to a specific version) upgrading `gcc-3.4' to `gcc-3.3.2' $ nix-env --upgrade pan (no upgrades available, so nothing happens) $ nix-env -u '*' (try to upgrade everything) upgrading `hello-2.1.2' to `hello-2.1.3' upgrading `mozilla-1.2' to `mozilla-1.4'
The upgrade operation determines whether a derivation
y
is an upgrade of a derivation
x
by looking at their respective
name
attributes. The names (e.g.,
gcc-3.3.1
are split into two parts: the package
name (gcc
), and the version
(3.3.1
). The version part starts after the first
dash not following by a letter. x
is considered an
upgrade of y
if their package names match, and the
version of y
is higher that that of
x
.
The versions are compared by splitting them into contiguous
components of numbers and letters. E.g., 3.3.1pre5
is split into [3, 3, 1, "pre", 5]
. These lists are
then compared lexicographically (from left to right). Corresponding
components a
and b
are compared
as follows. If they are both numbers, integer comparison is used. If
a
is an empty string and b
is a
number, a
is considered less than
b
. The special string component
pre
(for pre-release) is
considered to be less than other components. String components are
considered less than number components. Otherwise, they are compared
lexicographically (i.e., using case-sensitive string comparison).
This is illustrated by the following examples:
1.0 < 2.3 2.1 < 2.3 2.3 = 2.3 2.5 > 2.3 3.1 > 2.3 2.3.1 > 2.3 2.3.1 > 2.3a 2.3pre1 < 2.3 2.3pre3 < 2.3pre12 2.3a < 2.3c 2.3pre1 < 2.3c 2.3pre1 < 2.3q
--uninstall
--query
nix-env
{ --query
| -q
} [ --installed
| --available
| -a
] { --name
| --expr
| --status
| -s
}
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
).
The derivations are sorted by their name
attributes.
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.
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.
--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.
--no-name
Suppress printing of the name
attribute of each derivation.
--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.
$ nix-env -q (show installed derivations)
MozillaFirebird-0.7
bison-1.875c
docbook-xml-4.2
...
$ nix-env -qa (show available derivations)
GConf-2.4.0.1
MPlayer-1.0pre3
MozillaFirebird-0.7
ORBit2-2.8.3
...
$ nix-env -qas (show status of available derivations)
-P- GConf-2.4.0.1 (not installed but present)
--S MPlayer-1.0pre3 (not present, but there is a substitute for fast installation)
--S MozillaFirebird-0.7 (i.e., this is not the installed Firebird, even though the version is the same!)
IP- bison-1.875c (installed and by definition present)
...
$ nix-env -f ./foo.nix -qa (show available derivations in the Nix expression foo.nix
)
foo-1.2.3
--switch-profile
--list-generations
--delete-generations
--switch-generation
This operation makes generation number
generation
the current generation of the
active profile. That is, if the
is the path to
the active profile, then the symlink
profile
is made to
point to
profile
,
which is in turn a symlink to the actual user environment in the Nix
store.profile
-generation
-link
Switching will fail if the specified generation does not exist.
nix-build — build a Nix expression
nix-build
[--add-drv-link
] [--no-link
] paths
...
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.
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).
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.
--add-drv-link
Add a symlink in the current directory to the
store derivation produced by nix-instantiate.
The symlink is called derivation
(which is
numbered in the case of multiple derivations). The derivation is
a root of the garbage collector until the symlink is deleted or
renamed.
--no-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.
nix-store — manipulate or query the Nix store
nix-store
[--help
] [--version
] [--verbose
...] [-v
...] [--no-build-output
] [-Q
] [
{ --max-jobs
| -j
}
number
] [--keep-going
] [-k
] [--keep-failed
] [-K
] [--fallback
] [--readonly-mode
] [--log-type
type
] [--add-root
path
] [--indirect
] operation
[options
...] [arguments
...]
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. These are documented below.
This section lists the options that are common to all operations. These options are allowed for every subcommand, though they may not always have an effect. See also Section A.1, “Common options” for a list of common options.
--add-root
path
Causes the result of a realisation
(--realise
and --force-realise
)
to be registered as a root of the garbage collector (see Section 4.3.1, “Garbage collector roots”). The root is stored in
path
, which must be inside a directory
that is scanned for roots by the garbage collector (i.e.,
typically in a subdirectory of
/nix/var/nix/gcroots/
)
unless the --indirect
flag
is used.
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).
--indirect
In conjunction with --add-root
, this option
allows roots to be stored outside of the GC
roots directory. This is useful for commands such as
nix-build that place a symlink to the build
result in the current directory; such a build result should not be
garbage-collected unless the symlink is removed.
The --indirect
flag causes a uniquely named
symlink to path
to be stored in
/nix/var/nix/gcroots/auto/
. For instance,
$ nix-store --add-root /home/eelco/bla/result --indirect -r ...
$ 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.
Note that it is not possible to move or rename
indirect GC roots, since the symlink in the
auto
directory will still point to the old
location.
--realise
The operation --realise
essentially “builds”
the specified store paths. Realisation is a somewhat overloaded term:
If the store path is a derivation, realisation ensures that the output paths of the derivation are valid (i.e., the output path and its closure exist in the file system). This can be done in several ways. First, it is possible that the outputs are already valid, in which case we are done immediately. Otherwise, there may be substitutes that produce the outputs (e.g., by downloading them). Finally, the outputs can be produced by performing the build action described by the derivation.
If the store path is not a derivation, realisation ensures that the specified path is valid (i.e., it and its closure exist in the file system). If the path is already valid, we are done immediately. Otherwise, the path and any missing paths in its closure may be produced through substitutes. If there are no (succesful) subsitutes, realisation fails.
The output path of each derivation is printed on standard output. (For non-derivations argument, the argument itself is printed.)
This operation is typically used to build store derivations produced by nix-instantiate:
$ nix-store -r $(nix-instantiate ./test.nix) /nix/store/31axcgrlbfsxzmfff1gyj1bf62hvkby2-aterm-2.3.1
This is essentially what nix-build does.
--gc
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. What constitutes a root is described in Section 4.3.1, “Garbage collector roots”.
--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.
--delete
This operation performs an actual garbage collection. All dead paths are removed from the store. This is the default.
The behaviour of the collector is influenced by the gc-keep-outputs
and gc-keep-derivations
variables in the Nix configuration file.
--query
nix-store
{ --query
| -q
} { --outputs
| --requisites
| -R
| --references
| --referers
| --referers-closure
| --deriver
| --deriver
| --graph
| --tree
| --binding
name
| --hash
} [--use-output
] [-u
] [--force-realise
] [-f
] paths
...
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.
--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).
--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 output path 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
.)
--referers
Prints the set of referers 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 referers is not constant; it can change as
store paths are added or removed.
--referers-closure
Prints the closure of the set of store paths
paths
under the referers 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
Prints the deriver of 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.
--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.
--binding
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 path paths
. Since the hash is
stored in the Nix database, this is a fast
operation.
Print the closure (runtime dependencies) of the svn program in the current user environment:
$ nix-store -qR $(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 -qR $(nix-store -qd $(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 -q --tree $(nix-store -qd $(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 -q --referers $(nix-store -q --binding openssl $(nix-store -qd $(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 -q --referers-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 -q --graph ~/.nix-profile | dot -Tps > graph.ps $ gv graph.ps
--verify
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.
There is one option:
--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.
nix-instantiate — instantiate store derivations from Nix expressions
nix-instantiate
[--help
] [--version
] [--verbose
...] [-v
...] [--no-build-output
] [-Q
] [
{ --max-jobs
| -j
}
number
] [--keep-going
] [-k
] [--keep-failed
] [-K
] [--fallback
] [--readonly-mode
] [--log-type
type
] [--add-root
path
] [--indirect
] [ --parse-only
| --eval-only
] files
...
The command nix-instantiate generates store derivations from (high-level)
Nix expressions. It loads and evaluates the Nix expressions in each
of files
. Each top-level expression should
evaluate to a derivation, a list of derivations, or a set of
derivations. The paths of the resulting store derivations are printed
on standard output.
Most users and developers don’t need to use this command (nix-env and nix-build perform store derivation instantiation from Nix expressions automatically). It is most commonly used for implementing new deployment policies.
See also Section A.1, “Common options” for a list of common options.
--add-root
path
, --indirect
See the corresponding options in nix-store.
--parse-only
Just parse the input files, and print their abstract syntax trees on standard output in ATerm format.
--eval-only
Just parse and evaluate the input files, and print the resulting values on standard output. No instantiation of store derivations takes place.
$ nix-instantiate test.nix (instantiate)
/nix/store/cigxbmvy6dzix98dxxh9b6shg7ar5bvs-perl-BerkeleyDB-0.26.drv
$ nix-store -r $(nix-instantiate test.nix) (build)
...
/nix/store/qhqk4n8ci095g3sdp93x7rgwyh9rdvgk-perl-BerkeleyDB-0.26 (output path)
$ ls -l /nix/store/qhqk4n8ci095g3sdp93x7rgwyh9rdvgk-perl-BerkeleyDB-0.26
dr-xr-xr-x 2 eelco users 4096 1970-01-01 01:00 lib
...
nix-channel — manage Nix channels
nix-channel
{ --add
url
| --remove
url
| --list
| --update
}
A Nix channel is mechanism that allows you to automatically stay up-to-date with a set of pre-built Nix expressions. A Nix channel is just a URL that points to a place that contains a set of Nix expressions, as well as a nix-push manifest. See also Section 4.4, “Channels”.
This command has the following operations:
--add
url
Adds url
to the list of
subscribed channels.
--remove
url
Removes url
from the
list of subscribed channels.
--list
Prints the URLs of all subscribed channels on standard output.
--update
Downloads the Nix expressions of all subscribed channels, makes the conjunction of these the default for nix-env operations (by calling nix-env -I), and performs a nix-pull on the manifests of all channels to make pre-built binaries available.
Note that --add
and --remove
do not automatically perform an update.
The list of subscribed channels is stored in
~/.nix-channels
.
A channel consists of two elements: a bzipped Tar archive
containing the Nix expressions, and a manifest created by
nix-push. These must be stored under
and
url
/nixexprs.tar.bz2
,
respectively.url
/MANIFEST
nix-push — push store paths onto a network cache
nix-push
{{
archivesPutURL
archivesGetURL
manifestPutURL
} | {
--copy
archivesDir
manifestFile
}} paths
...
The command nix-push builds a set of store paths (if necessary), and then packages and uploads all store paths in the resulting closures to a server. A network cache thus populated can subsequently be used to speed up software deployment on other machines using the nix-pull command.
nix-push performs the following actions.
Each path in paths
is
realised (using nix-store
--realise
).
All paths in the closure of the store expressions
stored in paths
are determined (using
nix-store --query --requisites
--include-outputs
). It should be noted that since the
--include-outputs
flag is used, you get a combined
source/binary distribution.
All store paths determined in the previous step are
packaged and compressed into a bzipped NAR
archive (extension .nar.bz2
).
A manifest is created that contains information on the store paths, their eventual URLs in the cache, and cryptographic hashes of the contents of the NAR archives.
Each store path is uploaded to the remote directory
specified by archivesPutURL
. HTTP PUT
requests are used to do this. However, before a file
x
is uploaded to
,
nix-push first determines whether this upload is
unnecessary by issuing a HTTP HEAD request on
archivesPutURL
/x
.
This allows a cache to be shared between many partially overlapping
nix-push invocations. (We use two URLs because
the upload URL typically refers to a CGI script, while the download
URL just refers to a file system directory on the server.)archivesGetURL
/x
The manifest is uploaded using an HTTP PUT request
to manifestPutURL
. The corresponding
URL to download the manifest can then be used by
nix-pull.
TODO: --copy
To upload files there typically is some CGI script on the server
side. This script should be be protected with a password. The
following example uploads the store paths resulting from building the
Nix expressions in foo.nix
, passing appropriate
authentication information:
$ nix-push \ http://foo@bar:server.domain/cgi-bin/upload.pl/cache \ http://server.domain/cache \ http://foo@bar:server.domain/cgi-bin/upload.pl/MANIFEST \ $(nix-instantiate foo.nix)
This will push both sources and binaries (and any build-time dependencies used in the build, such as compilers).
If we just want to push binaries, not sources and build-time dependencies, we can do:
$ nix-push urls
$(nix-instantiate $(nix-store -r foo.nix))
nix-pull — pull substitutes from a network cache
nix-pull
url
The command nix-pull obtains a list of
pre-built store paths from the URL
url
, and for each of these store
paths, registers a substitute derivation that downloads and
unpacks it into the Nix store. This is used to speed up
installations: if you attempt to install something that has
already been built and stored into the network cache, Nix can
transparently re-use the pre-built store paths.
The file at url
must be compatible
with the files created by nix-push
.
nix-prefetch-url — copy a file from a URL into the store and print its MD5 hash
nix-prefetch-url
url
[hash
]
The command nix-prefetch-url downloads the
file referenced by the URL url
, prints its
cryptographic hash, and copies it into the Nix store. The file name
in the store is
,
where hash
-baseName
baseName
is everything following the
final slash in url
.
This command is just a convenience for Nix expression writers.
Often a Nix expression fetches some source distribution from the
network using the fetchurl
expression contained in
Nixpkgs. However, fetchurl
requires a
cryptographic hash. If you don't know the hash, you would have to
download the file first, and then fetchurl
would
download it again when you build your Nix expression. Since
fetchurl
uses the same name for the downloaded file
as nix-prefetch-url, the redundant download can be
avoided.
The environment variable NIX_HASH_ALGO
specifies
which hash algorithm to use. It can be either md5
,
sha1
, or sha256
. The default is
md5
.
If hash
is specified, then a download
is not performed if the Nix store already contains a file with the
same hash and base name. Otherwise, the file is downloaded, and an
error if signaled if the actual hash of the file does not match the
specified hash.
This command prints the hash on standard output. Additionally,
if the environment variable PRINT_PATH
is set, the path
of the downloaded file in the Nix store is also printed.
Table of Contents
This section provides solutions for some common problems.
Symptom: Nix operations (in particular the
nix-store operations --gc
,
--verify
, and --clear-substitutes
—
the latter being called by nix-channel --update)
failing:
$ nix-store --verify error: Db::del: Cannot allocate memory
Possible solution: make sure that no Nix processes are running, then do:
$ cd /nix/var/nix/db $ rm __db.00*
Symptom: when installing or upgrading, you get an error message such as
$ nix-env -i docbook-xml ... adding /nix/store/s5hyxgm62gk2...-docbook-xml-4.2 collission between `/nix/store/s5hyxgm62gk2...-docbook-xml-4.2/xml/dtd/docbook/calstblx.dtd' and `/nix/store/06h377hr4b33...-docbook-xml-4.3/xml/dtd/docbook/calstblx.dtd' at /nix/store/...-builder.pl line 62.
The cause is that two installed packages in the user environment
have overlapping filenames (e.g.,
xml/dtd/docbook/calstblx.dtd
. This usually
happens when you accidentally try to install two versions of the same
package. For instance, in the example above, the Nix Packages
collection contains two versions of docbook-xml
, so
nix-env -i will try to install both. The default
user environment builder has no way to way to resolve such conflicts,
so it just gives up.
Solution: remove one of the offending packages from the user
environment (if already installed) using nix-env
-u, or specify exactly which version should be installed
(e.g., nix-env -i docbook-xml-4.2
).
Alternatively, you can modify the user environment builder
script (in
)
to implement some conflict resolution policy. E.g., the script could
be modified to rename conflicting file names, or to pick one over the
other.prefix
/share/nix/corepkgs/buildenv/builder.pl
The man-pages generated from the DocBook documentation are ugly.
Generations properly form a tree. E.g., if after switching to generation 39, we perform an installation action, a generation 43 is created which is a descendant of 39, not 42. So a rollback from 43 ought to go back to 39. This is not currently implemented; generations form a linear sequence.
Build management. In principle it is already possible to do build management using Nix (by writing builders that perform appropriate build steps), but the Nix expression language is not yet powerful enough to make this pleasant (?). The language should be extended with features from the Maak build manager. Another interesting idea is to write a make implementation that uses Nix as a back-end to support legacy build files.
For security, nix-push manifests
should be digitally signed, and nix-pull should
verify the signatures. The actual NAR archives in the cache do not
need to be signed, since the manifest contains cryptographic hashes of
these files (and fetchurl.nix
checks
them).
It would be useful to have an option in nix-env --delete-generations to remove non-current generations older than a certain age.
There should be a flexible way to change the user
environment builder. Currently, you have to replace
,
which is hard-coded into nix-env. Also, the
default builder should be more powerful. For instance, there should
be some way to specify priorities to resolve
collisions.prefix
/share/nix/corepkgs/buildenv/builder.pl
A description of a build action. The result of a
derivation is a store object. Derivations are typically specified
in Nix expressions using the derivation
primitive. These are translated into low-level
store derivations (implicitly by
nix-env and nix-build, or
explicitly by nix-instantiate).
The location in the file system where store objects
live. Typically /nix/store
.
The location in the file system of a store object, i.e., an immediate child of the Nix store directory.
A file that is an immediate child of the Nix store directory. These can be regular files, but also entire directory trees. Store objects can be sources (objects copied from outside of the store), derivation outputs (objects produced by running a build action), or derivations (files describing a build action).
A substitute is a command invocation stored in the Nix database that describes how to build a store object, bypassing normal the build mechanism (i.e., derivations). Typically, the substitute builds the store object by downloading a pre-built version of the store object from some server.
The assumption that equal Nix derivations when run always produce the same output. This cannot be guaranteed in general (e.g., a builder can rely on external inputs such as the network or the system time) but the Nix model assumes it.
A high-level description of software components and compositions thereof. Deploying software using Nix entails writing Nix expressions for your components. Nix expressions are translated to derivations that are stored in the Nix store. These derivations can then be built.
A store path P
is said to have a
reference to a store path Q
if the store object
at P
contains the path Q
somewhere. This implies than an execution involving
P
potentially needs Q
to be
present. The references of a store path are
the set of store paths to which it has a reference.
The closure of a store path is the set of store
paths that are directly or indirectly “reachable” from that store
path; that is, it’s the closure of the path under the references relation. For instance,
if the store object at path P
contains a
reference to path Q
, then Q
is
in the closure of P
. For correct deployment it
is necessary to deploy whole closures, since otherwise at runtime
files could be missing. The command nix-store
-qR prints out closures of store paths.
A store path produced by a derivation.
The deriver of an output path is the store derivation that built it.
A store path is considered valid if it exists in the file system, is listed in the Nix database as being valid, and if all paths in its closure are also valid.
An automatically generated store object that consists of a set of symlinks to “active” applications, i.e., other store paths. These are generated automatically by nix-env. See Section 4.2, “Profiles”.
A symlink to the current user environment of a user, e.g.,
/nix/var/nix/profiles/default
.
Table of Contents
This bug fix release fixes two problems on Mac OS X:
If Nix was linked against statically linked versions of the ATerm or Berkeley DB library, there would be dynamic link errors at runtime.
nix-pull and
nix-push intermittently failed due to race
conditions involving pipes and child processes with error messages
such as open2: open(GLOB(0x180b2e4), >&=9) failed: Bad
file descriptor at /nix/bin/nix-pull line 77
(issue
NIX-14
).
This bug fix release addresses a problem with the ATerm library
when the --with-aterm
flag in
configure was not used.
NOTE: this version of Nix uses Berkeley DB 4.3 instead of 4.2. The database is upgraded automatically, but you should be careful not to use old versions of Nix that still use Berkeley DB 4.2. In particular, if you use a Nix installed through Nix, you should run
$ nix-store --clear-substitutes
first.
Unpacking of patch sequences is much faster now since we no longer do redundant unpacking and repacking of intermediate paths.
Nix now uses Berkeley DB 4.3.
The derivation
primitive is
lazier. Attributes of dependent derivations can mutually refer to
each other (as long as there are no data dependencies on the
outPath
and drvPath
attributes
computed by derivation
).
For example, the expression derivation
attrs
now evaluates to (essentially)
attrs // { type = "derivation"; outPath = derivation! attrs; drvPath = derivation! attrs; }
where derivation!
is a primop that does the
actual derivation instantiation (i.e., it does what
derivation
used to do). The advantage is that
it allows commands such as nix-env -qa and
nix-env -i to be much faster since they no longer
need to instantiate all derivations, just the
name
attribute.
Also, it allows derivations to cyclically reference each other, for example,
webServer = derivation { ... hostName = "svn.cs.uu.nl"; services = [svnService]; }; svnService = derivation { ... hostName = webServer.hostName; };
Previously, this would yield a black hole (infinite recursion).
nix-build now defaults to using
./default.nix
if no Nix expression is
specified.
nix-instantiate, when applied to a Nix expression that evaluates to a function, will call the function automatically if all its arguments have defaults.
Nix now uses libtool to build dynamic libraries. This reduces the size of executables.
A new list concatenation operator
++
. For example, [1 2 3] ++ [4 5
6]
evaluates to [1 2 3 4 5
6]
.
Some currently undocumented primops to support
low-level build management using Nix (i.e., using Nix as a Make
replacement). See the commit messages for r3578
and r3580
.
Various bug fixes and performance improvements.
This is a bug fix release.
Patch downloading was broken.
The garbage collector would not delete paths that had references from invalid (but substitutable) paths.
NOTE: the hashing scheme in Nix 0.8 changed (as detailed below). As a result, nix-pull manifests and channels built for Nix 0.7 and below will now work anymore. However, the Nix expression language has not changed, so you can still build from source. Also, existing user environments continue to work. Nix 0.8 will automatically upgrade the database schema of previous installations when it is first run.
If you get the error message
you have an old-style manifest `/nix/var/nix/manifests/[...]'; please delete it
you should delete previously downloaded manifests:
$ rm /nix/var/nix/manifests/*
If nix-channel gives the error message
manifest `http://catamaran.labs.cs.uu.nl/dist/nix/channels/[channel]/MANIFEST' is too old (i.e., for Nix <= 0.7)
then you should unsubscribe from the offending channel
(nix-channel --remove
URL
; leave out
/MANIFEST
), and subscribe to the same URL, with
channels
replaced by channels-v3
(e.g.,
http://catamaran.labs.cs.uu.nl/dist/nix/channels-v3/nixpkgs-unstable).
Nix 0.8 has the following improvements:
The cryptographic hashes used in store paths are now 160 bits long, but encoded in base-32 so that they are still only 32 characters long (e.g., /nix/store/csw87wag8bqlqk7ipllbwypb14xainap-atk-1.9.0). (This is actually a 160 bit truncation of a SHA-256 hash.)
Big cleanups and simplifications of the basic store semantics. The notion of "closure store expressions" is gone (and so is the notion of "successors"); the file system references of a store path are now just stored in the database.
For instance, given any store path, you can query its closure:
$ nix-store -qR $(which firefox) ... lots of paths ...
Also, Nix now remembers for each store path the derivation that built it (the "deriver"):
$ nix-store -qR $(which firefox) /nix/store/4b0jx7vq80l9aqcnkszxhymsf1ffa5jd-firefox-1.0.1.drv
So to see the build-time dependencies, you can do
$ nix-store -qR $(nix-store -qd $(which firefox))
or, in a nicer format:
$ nix-store -q --tree $(nix-store -qd $(which firefox))
File system references are also stored in reverse. For instance, you can query all paths that directly or indirectly use a certain Glibc:
$ nix-store -q --referers-closure \ /nix/store/8lz9yc6zgmc0vlqmn2ipcpkjlmbi51vv-glibc-2.3.4
The concept of fixed-output derivations has been
formalised. Previously, functions such as
fetchurl
in Nixpkgs used a hack (namely,
explicitly specifying a store path hash) to prevent changes to, say,
the URL of the file from propagating upwards through the dependency
graph, causing rebuilds of everything. This can now be done cleanly
by specifying the outputHash
and
outputHashAlgo
attributes. Nix itself checks
that the content of the output has the specified hash. (This is
important for maintaining certain invariants necessary for future
work on secure shared stores.)
One-click installation :-) It is now possible to
install any top-level component in Nixpkgs directly, through the web
- see, e.g., http://catamaran.labs.cs.uu.nl/dist/nixpkgs-0.8/. All
you have to do is associate
/nix/bin/nix-install-package
with the MIME type
application/nix-package
(or the extension
.nixpkg
), and clicking on a package link will
cause it to be installed, with all appropriate dependencies. If you
just want to install some specific application, this is easier than
subscribing to a channel.
nix-store -r
PATHS
now builds all the
derivations PATHS in parallel. Previously it did them sequentially
(though exploiting possible parallelism between subderivations).
This is nice for build farms.
nix-channel has new operations
--list
and
--remove
.
New ways of installing components into user environments:
Copy from another user environment:
$ nix-env -i --from-profile .../other-profile firefox
Install a store derivation directly (bypassing the Nix expression language entirely):
$ nix-env -i /nix/store/z58v41v21xd3...-aterm-2.3.1.drv
(This is used to implement nix-install-package, which is therefore immune to evolution in the Nix expression language.)
Install an already built store path directly:
$ nix-env -i /nix/store/hsyj5pbn0d9i...-aterm-2.3.1
Install the result of a Nix expression specified as a command-line argument:
$ nix-env -f .../i686-linux.nix -i -E 'x: x.firefoxWrapper'
The difference with the normal installation mode is that
-E
does not use the name
attributes of derivations. Therefore, this can be used to
disambiguate multiple derivations with the same
name.
A hash of the contents of a store path is now stored in the database after a succesful build. This allows you to check whether store paths have been tampered with: nix-store --verify --check-contents.
Implemented a concurrent garbage collector. It is now always safe to run the garbage collector, even if other Nix operations are happening simultaneously.
However, there can still be GC races if you use
nix-instantiate and nix-store
--realise directly to build things. To prevent races,
use the --add-root
flag of those commands.
The garbage collector now finally deletes paths in the right order (i.e., topologically sorted under the “references” relation), thus making it safe to interrupt the collector without risking a store that violates the closure invariant.
Likewise, the substitute mechanism now downloads files in the right order, thus preserving the closure invariant at all times.
The result of nix-build is now
registered as a root of the garbage collector. If the
./result
link is deleted, the GC root
disappears automatically.
The behaviour of the garbage collector can be changed
globally by setting options in
/nix/etc/nix/nix.conf
.
gc-keep-derivations
specifies
whether deriver links should be followed when searching for live
paths.
gc-keep-outputs
specifies
whether outputs of derivations should be followed when searching
for live paths.
env-keep-derivations
specifies whether user environments should store the paths of
derivations when they are added (thus keeping the derivations
alive).
New nix-env query flags
--drv-path
and
--out-path
.
fetchurl allows SHA-1 and SHA-256
in addition to MD5. Just specify the attribute
sha1
or sha256
instead of
md5
.
Manual updates.
Binary patching. When upgrading components using pre-built binaries (through nix-pull / nix-channel), Nix can automatically download and apply binary patches to already installed components instead of full downloads. Patching is "smart": if there is a *sequence* of patches to an installed component, Nix will use it. Patches are currently generated automatically between Nixpkgs (pre-)releases.
Simplifications to the substitute mechanism.
Nix-pull now stores downloaded manifests in /nix/var/nix/manifests.
Metadata on files in the Nix store is canonicalised after builds: the last-modified timestamp is set to 0 (00:00:00 1/1/1970), the mode is set to 0444 or 0555 (readable and possibly executable by all; setuid/setgid bits are dropped), and the group is set to the default. This ensures that the result of a build and an installation through a substitute is the same; and that timestamp dependencies are revealed.
Rewrite of the normalisation engine.
Multiple builds can now be performed in parallel
(option -j
).
Distributed builds. Nix can now call a shell script to forward builds to Nix installations on remote machines, which may or may not be of the same platform type.
Option --fallback
allows
recovery from broken substitutes.
Option --keep-going
causes
building of other (unaffected) derivations to continue if one
failed.
Improvements to the garbage collector (i.e., it should actually work now).
Setuid Nix installations allow a Nix store to be shared among multiple users.
Substitute registration is much faster now.
A utility nix-build to build a Nix expression and create a symlink to the result int the current directory; useful for testing Nix derivations.
Manual updates.
nix-env changes:
Derivations for other platforms are filtered out
(which can be overriden using
--system-filter
).
--install
by default now
uninstall previous derivations with the same
name.
--upgrade
allows upgrading to a
specific version.
New operation
--delete-generations
to remove profile
generations (necessary for effective garbage
collection).
Nicer output (sorted, columnised).
More sensible verbosity levels all around (builder
output is now shown always, unless -Q
is
given).
Nix expression language changes:
New language construct: with
brings all attributes
defined in the attribute set E1
;
E2
E1
in
scope in E2
.
Added a map
function.
Various new operators (e.g., string concatenation).
Expression evaluation is much faster.
An Emacs mode for editing Nix expressions (with syntax highlighting and indentation) has been added.
Many bug fixes.