| nix(1) | General Commands Manual | nix(1) |
Warning
This program is experimental and its interface is subject to
change.
nix - a tool for reproducible and declarative configuration management
nix [option…] subcommand
where subcommand is one of the following:
Help commands:
Main commands:
Main commands:
Infrequently used commands:
Utility/scripting commands:
Commands for upgrading or troubleshooting your Nix installation:
# nix flake new hello # cd hello
# nix build # ./result/bin/hello Hello, world!
# nix run Hello, world!
# nix develop # unpackPhase # cd hello-* # configurePhase # buildPhase # ./hello Hello, world! # installPhase # ../outputs/out/bin/hello Hello, world!
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.
Warning
Installables are part of the unstable
nix-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:
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.
Warning
Flake output attribute installables depend on both the
flakes and
nix-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:
. └── baz ├── blah │ └── file.txt └── flake.nix
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.
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^*
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.
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>).
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:
# nix build 'nixpkgs#glibc^dev,static' # ls ./result-dev/include/ ./result-static/lib/ …
# nix build '/nix/store/gzaflydcr6sb3567hap9q6srzx8ggdgg-glibc-2.33-78.drv^dev,static' …
# 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
# nix path-info --closure-size '/nix/store/gzaflydcr6sb3567hap9q6srzx8ggdgg-glibc-2.33-78.drv^*' …
# nix eval 'nixpkgs#libxml2.meta.outputsToInstall' [ "bin" "man" ]
Most nix subcommands operate on a Nix store. These are documented in nix help-stores.
Logging-related options:
Miscellaneous global options:
Options to override configuration settings: