keep-outputs = true       # Nice for developers
keep-derivations = true   # Idem

Note that trusted users are always allowed to connect.

Therefore, if this option is non-empty and specifies a valid group, builds will be performed under the user accounts that are a member of the group specified here (as listed in /etc/group). Those user accounts should not be used for any other purpose!

Nix will never run two builds under the same user account at the same time. This is to prevent an obvious security hole: a malicious user writing a Nix expression that modifies the build result of a legitimate Nix expression being built by another user. Therefore it is good to have as many Nix build user accounts as you can spare. (Remember: uids are cheap.)

The build users should have permission to create files in the Nix store, but not delete them. Therefore, /nix/store should be owned by the Nix account, its group should be the group specified here, and its mode should be 1775.

If the build users group is empty, builds will be performed under the uid of the Nix process (that is, the uid of the caller if NIX_REMOTE is empty, the uid under which the Nix daemon runs if NIX_REMOTE is daemon). Obviously, this should not be used in multi-user settings with untrusted users.

See also Chapter 17, Tuning Cores and Jobs.

The diff hook is executed by the same user and group who ran the build. However, the diff hook does not have write access to the store path just built.

The diff hook program receives three parameters:

The stderr and stdout output from the diff hook will not be displayed to the user. Instead, it will print to the nix-daemon's log.

When using the Nix daemon, diff-hook must be set in the nix.conf configuration file, and cannot be passed at the command line.

builtins.fetchurl {
  url = https://example.org/foo-1.2.3.tar.xz;
  sha256 = "2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae";
}

Nix will attempt to download this file from http://tarballs.nixos.org/sha256/2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae first. If it is not available there, if will try the original URI.

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 save a bit of disk space (or a lot if keep-outputs is also turned on).

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 keep-outputs.

The difference between this option and keep-derivations is that this one is “sticky”: it applies to any user environment created while this option was enabled, while keep-derivations only applies at the moment the garbage collector is run.

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.

See also Chapter 17, Tuning Cores and Jobs.

The value 0 means that there is no timeout. This is also the default.

The netrc file consists of a list of accounts in the following format:

machine my-machine
login my-username
password my-password

For the exact syntax, see the curl documentation.[1]

Since these files are loaded into the same address space as Nix itself, they must be DSOs compatible with the instance of Nix running at the time (i.e. compiled against the same headers, not linked to any incompatible libraries). They should not be linked to any Nix libs directly, as those will be available already at load time.

If an entry in the list is a directory, all files in the directory are loaded as plugins (non-recursively).

The hook is passed the derivation path and, if sandboxes are enabled, the sandbox directory. It can then modify the sandbox and send a series of commands to modify various settings to stdout. The currently recognized commands are:

extra-sandbox-paths

This option is only settable in the global nix.conf, or on the command line by trusted users.

When using the nix-daemon, the daemon executes the hook as root. If the nix-daemon is not involved, the hook runs as the user executing the nix-build.

The program executes with no arguments. The program's environment contains the following environment variables:

DRV_PATH

OUT_PATHS

See Chapter 19, Using the post-build-hook for an example implementation.

When using the Nix daemon, run-diff-hook must be set in the nix.conf configuration file, and cannot be passed at the command line.

Currently, sandboxing only work on Linux and macOS. The use of a sandbox requires that Nix is run as root (so you should use the “build users” feature to perform the actual builds under different users than root).

If this option is set to relaxed, then fixed-output derivations and derivations that have the __noChroot attribute set to true do not run in sandboxes.

The default is true on Linux and false on all other platforms.

Depending on how Nix was built, the default value for this option may be empty or provide /bin/sh as a bind-mount of bash.

It defaults to the canonical Nix system name detected by configure at build time.

requiredSystemFeatures = [ "kvm" ];

ensures that the derivation can only be built on a machine with the kvm feature.

This setting by default includes kvm if /dev/kvm is accessible, and the pseudo-features nixos-test, benchmark and big-parallel that are used in Nixpkgs to route builds to specific machines.

The number of seconds a downloaded tarball is considered fresh. If the cached tarball is stale, Nix will check whether it is still up to date using the ETag header. Nix will download a new version if the ETag header is unsupported, or the cached ETag doesn't match.

Setting the TTL to 0 forces Nix to always check if the tarball is up to date.

Nix caches tarballs in $XDG_CACHE_HOME/nix/tarballs.

Files fetched via NIX_PATH, fetchGit, fetchMercurial, fetchTarball, and fetchurl respect this TTL.

The value 0 means that there is no timeout. This is also the default.

If set to true, the Nix evaluator will trace every function call. Nix will print a log message at the "vomit" level for every function entrance and function exit.

function-trace entered undefined position at 1565795816999559622
function-trace exited undefined position at 1565795816999581277
function-trace entered /nix/store/.../example.nix:226:41 at 1565795253249935150
function-trace exited /nix/store/.../example.nix:226:41 at 1565795253249941684

Use the contrib/stack-collapse.py script distributed with the Nix source code to convert the trace logs in to a format suitable for flamegraph.pl.