Warning
This program is experimental and its interface is subject to change.
Name
nix
- a tool for reproducible and declarative configuration management
Synopsis
nix
[option...] subcommand
where subcommand is one of the following:
Help commands:
nix help
- show help aboutnix
or a particular subcommandnix help-stores
- show help about store types and their settings
Main commands:
nix build
- build a derivation or fetch a store pathnix develop
- run a bash shell that provides the build environment of a derivationnix flake
- manage Nix flakesnix profile
- manage Nix profilesnix run
- run a Nix applicationnix search
- search for packagesnix shell
- run a shell in which the specified packages are available
Main commands:
nix repl
- start an interactive environment for evaluating Nix expressions
Infrequently used commands:
nix bundle
- bundle an application so that it works outside of the Nix storenix copy
- copy paths between Nix storesnix edit
- open the Nix expression of a Nix package in $EDITORnix eval
- evaluate a Nix expressionnix fmt
- reformat your code in the standard stylenix log
- show the build log of the specified packages or paths, if availablenix path-info
- query information about store pathsnix registry
- manage the flake registrynix why-depends
- show why a package has another package in its closure
Utility/scripting commands:
nix daemon
- daemon to perform store operations on behalf of non-root clientsnix derivation
- Work with derivations, Nix's notion of a build plan.nix hash
- compute and convert cryptographic hashesnix key
- generate and convert Nix signing keysnix nar
- create or inspect NAR filesnix print-dev-env
- print shell code that can be sourced by bash to reproduce the build environment of a derivationnix realisation
- manipulate a Nix realisationnix show-config
- show the Nix configuration or the value of a specific settingnix store
- manipulate a Nix store
Commands for upgrading or troubleshooting your Nix installation:
nix doctor
- check your system for potential problems and print a PASS or FAIL for each checknix upgrade-nix
- upgrade Nix to the latest stable version
Examples
-
Create a new flake:
# nix flake new hello # cd hello
-
Build the flake in the current directory:
# nix build # ./result/bin/hello Hello, world!
-
Run the flake in the current directory:
# nix run Hello, world!
-
Start a development shell for hacking on this flake:
# nix develop # unpackPhase # cd hello-* # configurePhase # buildPhase # ./hello Hello, world! # installPhase # ../outputs/out/bin/hello Hello, world!
Description
Nix is a tool for building software, configurations and other artifacts in a reproducible and declarative way. For more information, see the Nix homepage or the Nix manual.
Installables
Warning
Installables are part of the unstablenix-command
experimental feature, and subject to change without notice.
Many nix
subcommands operate on one or more installables.
These are command line arguments that represent something that can be realised in the Nix store.
The following types of installable are supported by most commands:
- Flake output attribute (experimental)
- Store path
- Nix file, optionally qualified by an attribute path
- Nix expression, optionally qualified by an attribute path
For most commands, if no installable is specified, .
is assumed.
That is, Nix will operate on the default flake output attribute of the flake in the current directory.
Flake output attribute
Warning
Flake output attribute installables depend on both theflakes
andnix-command
experimental features, and subject to change without notice.
Example: nixpkgs#hello
These have the form flakeref[#
attrpath], where flakeref is a
flake reference and attrpath is an optional attribute path. For
more information on flakes, see the nix flake
manual
page. Flake references are most commonly a flake
identifier in the flake registry (e.g. nixpkgs
), or a raw path
(e.g. /path/to/my-flake
or .
or ../foo
), or a full URL
(e.g. github:nixos/nixpkgs
or path:.
)
When the flake reference is a raw path (a path without any URL
scheme), it is interpreted as a path:
or git+file:
url in the following
way:
-
If the path is within a Git repository, then the url will be of the form
git+file://[GIT_REPO_ROOT]?dir=[RELATIVE_FLAKE_DIR_PATH]
whereGIT_REPO_ROOT
is the path to the root of the git repository, andRELATIVE_FLAKE_DIR_PATH
is the path (relative to the directory root) of the closest parent of the given path that contains aflake.nix
within the git repository. If no such directory exists, then Nix will error-out.Note that the search will only include files indexed by git. In particular, files which are matched by
.gitignore
or have never beengit add
-ed will not be available in the flake. If this is undesirable, specifypath:<directory>
explicitly;For example, if
/foo/bar
is a git repository with the following structure:. └── baz ├── blah │ └── file.txt └── flake.nix
Then
/foo/bar/baz/blah
will resolve togit+file:///foo/bar?dir=baz
-
If the supplied path is not a git repository, then the url will have the form
path:FLAKE_DIR_PATH
whereFLAKE_DIR_PATH
is the closest parent of the supplied path that contains aflake.nix
file (within the same file-system). If no such directory exists, then Nix will error-out.For example, if
/foo/bar/flake.nix
exists, then/foo/bar/baz/
will resolve topath:/foo/bar
If attrpath is omitted, Nix tries some default values; for most
subcommands, the default is packages.
system.default
(e.g. packages.x86_64-linux.default
), but some subcommands have
other defaults. If attrpath is specified, attrpath is
interpreted as relative to one or more prefixes; for most
subcommands, these are packages.
system,
legacyPackages.*system*
and the empty prefix. Thus, on
x86_64-linux
nix build nixpkgs#hello
will try to build the
attributes packages.x86_64-linux.hello
,
legacyPackages.x86_64-linux.hello
and hello
.
If attrpath begins with .
then no prefixes or defaults are attempted. This allows the form flakeref[#.
attrpath], such as github:NixOS/nixpkgs#.lib.fakeSha256
to avoid a search of packages.*system*.lib.fakeSha256
Store path
Example: /nix/store/v5sv61sszx301i0x6xysaqzla09nksnd-hello-2.10
These are paths inside the Nix store, or symlinks that resolve to a path in the Nix store.
A store derivation is also addressed by store path.
Example: /nix/store/p7gp6lxdg32h4ka1q398wd9r2zkbbz2v-hello-2.10.drv
If you want to refer to an output path of that store derivation, add the output name preceded by a caret (^
).
Example: /nix/store/p7gp6lxdg32h4ka1q398wd9r2zkbbz2v-hello-2.10.drv^out
All outputs can be referred to at once with the special syntax ^*
.
Example: /nix/store/p7gp6lxdg32h4ka1q398wd9r2zkbbz2v-hello-2.10.drv^*
Nix file
Example: --file /path/to/nixpkgs hello
When the option -f
/ --file
path [attrpath...] is given, installables are interpreted as the value of the expression in the Nix file at path.
If attribute paths are provided, commands will operate on the corresponding values accessible at these paths.
The Nix expression in that file, or any selected attribute, must evaluate to a derivation.
Nix expression
Example: --expr 'import <nixpkgs> {}' hello
When the option --expr
expression [attrpath...] is given, installables are interpreted as the value of the of the Nix expression.
If attribute paths are provided, commands will operate on the corresponding values accessible at these paths.
The Nix expression, or any selected attribute, must evaluate to a derivation.
You may need to specify --impure
if the expression references impure inputs (such as <nixpkgs>
).
Derivation output selection
Derivations can have multiple outputs, each corresponding to a
different store path. For instance, a package can have a bin
output
that contains programs, and a dev
output that provides development
artifacts like C/C++ header files. The outputs on which nix
commands
operate are determined as follows:
-
You can explicitly specify the desired outputs using the syntax installable
^
output1,
...,
outputN. For example, you can obtain thedev
andstatic
outputs of theglibc
package:# nix build 'nixpkgs#glibc^dev,static' # ls ./result-dev/include/ ./result-static/lib/ …
and likewise, using a store path to a "drv" file to specify the derivation:
# nix build '/nix/store/gzaflydcr6sb3567hap9q6srzx8ggdgg-glibc-2.33-78.drv^dev,static' …
-
You can also specify that all outputs should be used using the syntax installable
^*
. For example, the following shows the size of all outputs of theglibc
package in the binary cache:# nix path-info --closure-size --eval-store auto --store https://cache.nixos.org 'nixpkgs#glibc^*' /nix/store/g02b1lpbddhymmcjb923kf0l7s9nww58-glibc-2.33-123 33208200 /nix/store/851dp95qqiisjifi639r0zzg5l465ny4-glibc-2.33-123-bin 36142896 /nix/store/kdgs3q6r7xdff1p7a9hnjr43xw2404z7-glibc-2.33-123-debug 155787312 /nix/store/n4xa8h6pbmqmwnq0mmsz08l38abb06zc-glibc-2.33-123-static 42488328 /nix/store/q6580lr01jpcsqs4r5arlh4ki2c1m9rv-glibc-2.33-123-dev 44200560
and likewise, using a store path to a "drv" file to specify the derivation:
# nix path-info --closure-size '/nix/store/gzaflydcr6sb3567hap9q6srzx8ggdgg-glibc-2.33-78.drv^*' …
-
If you didn't specify the desired outputs, but the derivation has an attribute
meta.outputsToInstall
, Nix will use those outputs. For example, since the packagenixpkgs#libxml2
has this attribute:# nix eval 'nixpkgs#libxml2.meta.outputsToInstall' [ "bin" "man" ]
a command like
nix shell nixpkgs#libxml2
will provide only those two outputs by default.Note that a store derivation (given by its
.drv
file store path) doesn't have any attributes likemeta
, and thus this case doesn't apply to it. -
Otherwise, Nix will use all outputs of the derivation.
Nix stores
Most nix
subcommands operate on a Nix store. These are documented
in nix help-stores
.
Shebang interpreter
The nix
command can be used as a #!
interpreter.
Arguments to Nix can be passed on subsequent lines in the script.
Verbatim strings may be passed in double backtick (``
) quotes.
Sequences of n backticks of 3 or longer are parsed as n-1 literal backticks.
A single space before the closing ``
is ignored if present.
--file
and --expr
resolve relative paths based on the script location.
Examples:
#!/usr/bin/env nix
#! nix shell --file ``<nixpkgs>`` hello cowsay --command bash
hello | cowsay
or with flakes:
#!/usr/bin/env nix
#! nix shell nixpkgs#bash nixpkgs#hello nixpkgs#cowsay --command bash
hello | cowsay
or with an expression:
#! /usr/bin/env nix
#! nix shell --impure --expr ``
#! nix with (import (builtins.getFlake "nixpkgs") {});
#! nix terraform.withPlugins (plugins: [ plugins.openstack ])
#! nix ``
#! nix --command bash
terraform "$@"
or with cascading interpreters. Note that the #! nix
lines don't need to follow after the first line, to accomodate other interpreters.
#!/usr/bin/env nix
//! ```cargo
//! [dependencies]
//! time = "0.1.25"
//! ```
/*
#!nix shell nixpkgs#rustc nixpkgs#rust-script nixpkgs#cargo --command rust-script
*/
fn main() {
for argument in std::env::args().skip(1) {
println!("{}", argument);
};
println!("{}", std::env::var("HOME").expect(""));
println!("{}", time::now().rfc822z());
}
// vim: ft=rust
Options
Logging-related options
-
Set the logging verbosity level to 'debug'.
-
--log-format
formatSet the format of log output; one of
raw
,internal-json
,bar
orbar-with-logs
. -
--print-build-logs
/-L
Print full build logs on standard error.
-
Decrease the logging verbosity level.
-
--verbose
/-v
Increase the logging verbosity level.
Miscellaneous global options
-
Show usage information.
-
Disable substituters and consider all previously downloaded files up-to-date.
-
--option
name valueSet the Nix configuration setting name to value (overriding
nix.conf
). -
Consider all previously downloaded files out-of-date.
-
Show version information.
Note
See
man nix.conf
for overriding configuration settings with command line flags.