nix - a tool for reproducible and declarative configuration management

       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.

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

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:

       •  Flake output attribute (experimental)

          •  This is the default
       •  Store path

          •  This is assumed if the argument is a Nix store path or a symlink to a Nix store path
       •  Nix file, optionally qualified by an attribute path

          •  Specified with --file/-f
       •  Nix expression, optionally qualified by an attribute path

          •  Specified with --expr/-E

       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.

   FlakeoutputattributeWarning
              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:

       •  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]  where  GIT_REPO_ROOT is the path to the root
          of the git repository, and RELATIVE_FLAKE_DIR_PATH is the path (relative to the directory root) of the
          closest parent of the given path that contains a flake.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 been git add-ed will not be available in the flake. If this is undesirable,
          specify path:<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 to git+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
          where FLAKE_DIR_PATH is the closest parent of the supplied path that contains a flake.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 to path:/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  attrpathis  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

   Storepath
       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^*

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

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

   Derivationoutputselection
       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 — that
          is, a caret followed immediately by a comma-separated list  of  derivation  outputs  to  select.   For
          installables  specified as Flake output attributes or Store paths, the output is specified in the same
          argument:

          For example, you can obtain the dev and static outputs of the glibc 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'
       …

              For -e/--expr and -f/--file, the derivation output is specified as part of the attribute path:

       $ nix build -f '<nixpkgs>' 'glibc^dev,static'
       $ nix build --impure -E 'import <nixpkgs> { }' 'glibc^dev,static'

              This syntax is the same even if the actual attribute path is empty:

       $ nix build -E 'let pkgs = import <nixpkgs> { }; in pkgs.glibc' '^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 the glibc 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 package nixpkgs#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 doesn’t have any attributes like meta, and  thus  this  case  doesn’t
              apply to it.

       •  Otherwise, Nix will use all outputs of the derivation.

       nix - a tool for reproducible and declarative configuration management

       Most  nix  subcommands operate on a Nixstore.  The various store types are documented in the Store Types
       section of the manual.

       The same information is also available from the nix help-stores command.

Logging-relatedoptions
       •  --debug

          Set the logging verbosity level to ‘debug’.

       •  --log-format format

          Set the format of log output; one of raw, internal-json, bar or bar-with-logs.

       •  --print-build-logs / -L

          Print full build logs on standard error.

       •  --quiet

          Decrease the logging verbosity level.

       •  --verbose / -v

          Increase the logging verbosity level.

   Miscellaneousglobaloptions
       •  --help

          Show usage information.

       •  --offline

          Disable substituters and consider all previously downloaded files up-to-date.

       •  --option namevalue

          Set the Nix configuration setting name to value (overriding nix.conf).

       •  --refresh

          Consider all previously downloaded files out-of-date.

       •  --version

          Show version information.

          Note

          See man nix.conf for overriding configuration settings with command line flags.

                                                                                                          nix(1)

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

       nix [option…] subcommand

       where subcommand is one of the following:

       Helpcommands:

       •  nix help - show help about nix or a particular subcommand
       •  nix help-stores - show help about store types and their settings

       Maincommands:

       •  nix build - build a derivation or fetch a store path
       •  nix develop - run a bash shell that provides the build environment of a derivation
       •  nix flake - manage Nix flakes
       •  nix profile - manage Nix profiles
       •  nix run - run a Nix application
       •  nix search - search for packages

       Maincommands:

       •  nix repl - start an interactive environment for evaluating Nix expressions

       Infrequentlyusedcommands:

       •  nix bundle - bundle an application so that it works outside of the Nix store
       •  nix copy - copy paths between Nix stores
       •  nix edit - open the Nix expression of a Nix package in $EDITOR
       •  nix eval - evaluate a Nix expression
       •  nix fmt - reformat your code in the standard style
       •  nix log - show the build log of the specified packages or paths, if available
       •  nix path-info - query information about store paths
       •  nix registry - manage the flake registry
       •  nix why-depends - show why a package has another package in its closure

       Utility/scriptingcommands:

       •  nix config - manipulate the Nix configuration
       •  nix daemon - daemon to perform store operations on behalf of non-root clients
       •  nix derivation - Work with derivations, Nix’s notion of a build plan.
       •  nix env - manipulate the process environment
       •  nix hash - compute and convert cryptographic hashes
       •  nix key - generate and convert Nix signing keys
       •  nix nar - create or inspect NAR files
       •  nix print-dev-env - print shell code that can be sourced by bash to reproduce the build environment of
          a derivation
       •  nix realisation - manipulate a Nix realisation
       •  nix store - manipulate a Nix store

       CommandsforupgradingortroubleshootingyourNixinstallation:

       •  nix upgrade-nix - upgrade Nix to the latest stable version