R""(
Create a new flake:
Build the flake in the current directory:
Run the flake in the current directory:
Start a development shell for hacking on this flake:
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:
--file
/-f
--expr
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
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
manualpage". Flake references are most commonly a flake
identifier in the flake registry (e.g. <tt>nixpkgs</tt>), or a raw path
(e.g. <tt>/path/to/my-flake</tt> or <tt>.</tt> or <tt>../foo</tt>), or a full URL
(e.g. <tt>github:nixos/nixpkgs</tt> or <tt>path:.</tt>)
When the flake reference is a raw path (a path without any URL
scheme), it is interpreted as a <tt>path:</tt> or <tt>git+file:</tt> url in the following
way:
- If the path is within a Git repository, then the url will be of the form
<tt>git+file://[GIT_REPO_ROOT]?dir=[RELATIVE_FLAKE_DIR_PATH]</tt>
where <tt>GIT_REPO_ROOT</tt> is the path to the root of the git repository,
and <tt>RELATIVE_FLAKE_DIR_PATH</tt> is the path (relative to the directory
root) of the closest parent of the given path that contains a <tt>flake.nix</tt> 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 <tt>.gitignore</tt> or have never been <tt>git add</tt>-ed will not be
available in the flake. If this is undesirable, specify <tt>path:\<directory\></tt> explicitly;
For example, if <tt>/foo/bar</tt> is a git repository with the following structure:
@icode
.
└── baz
├── blah
│ └── file.txt
└── flake.nix
@endicode
Then <tt>/foo/bar/baz/blah</tt> will resolve to <tt>git+file:///foo/bar?dir=baz</tt>
- If the supplied path is not a git repository, then the url will have the form
<tt>path:FLAKE_DIR_PATH</tt> where <tt>FLAKE_DIR_PATH</tt> is the closest parent
of the supplied path that contains a <tt>flake.nix</tt> file (within the same file-system).
If no such directory exists, then Nix will error-out.
For example, if <tt>/foo/bar/flake.nix</tt> exists, then <tt>/foo/bar/baz/</tt> will resolve to
<tt>path:/foo/bar</tt>
If <em>attrpath</em> is omitted, Nix tries some default values; for most
subcommands, the default is <tt>packages.</tt>*system*<tt>.default</tt>
(e.g. <tt>packages.x86_64-linux.default</tt>), but some subcommands have
other defaults. If <em>attrpath</em> <em>is</em> specified, <em>attrpath</em> is
interpreted as relative to one or more prefixes; for most
subcommands, these are <tt>packages.</tt>*system*,
<tt>legacyPackages.*system*</tt> and the empty prefix. Thus, on
<tt>x86_64-linux</tt> <tt>nix build nixpkgs\#hello</tt> will try to build the
attributes <tt>packages.x86_64-linux.hello</tt>,
<tt>legacyPackages.x86_64-linux.hello</tt> and <tt>hello</tt>.
If <em>attrpath</em> begins with <tt>.</tt> then no prefixes or defaults are attempted. This allows the form <em>flakeref</em>[<tt>\#.</tt>*attrpath*], such as <tt>github:NixOS/nixpkgs\#.lib.fakeSha256</tt> to avoid a search of <tt>packages.*system*.lib.fakeSha256</tt>
@subsubsection autotoc_md96 Store path
Example: <tt>/nix/store/v5sv61sszx301i0x6xysaqzla09nksnd-hello-2.10</tt>
These are paths inside the Nix store, or symlinks that resolve to a path in the Nix store.
A <a href="@docroot@/glossary.md#gloss-store-derivation" >store derivation</a> is also addressed by store path.
Example: <tt>/nix/store/p7gp6lxdg32h4ka1q398wd9r2zkbbz2v-hello-2.10.drv</tt>
If you want to refer to an output path of that store derivation, add the output name preceded by a caret (<tt>^</tt>).
Example: <tt>/nix/store/p7gp6lxdg32h4ka1q398wd9r2zkbbz2v-hello-2.10.drv^out</tt>
All outputs can be referred to at once with the special syntax <tt>^*</tt>.
Example: <tt>/nix/store/p7gp6lxdg32h4ka1q398wd9r2zkbbz2v-hello-2.10.drv^*</tt>
@subsubsection autotoc_md97 Nix file
Example: <tt>--file /path/to/nixpkgs hello</tt>
When the option <tt>-f</tt> / <tt>--file</tt> <em>path</em> [<em>attrpath</em>...] is given, installables are interpreted as the value of the expression in the Nix file at <em>path</em>.
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.
@subsubsection autotoc_md98 Nix expression
Example: ‘--expr 'import <nixpkgs> {}’ hello`
When the option <tt>--expr</tt> <em>expression</em> [<em>attrpath</em>...] 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 <tt>--impure</tt> if the expression references impure inputs (such as <tt>\<nixpkgs\></tt>).
@subsection autotoc_md99 Derivation output selection
Derivations can have multiple outputs, each corresponding to a
different store path. For instance, a package can have a <tt>bin</tt> output
that contains programs, and a <tt>dev</tt> output that provides development
artifacts like C/C++ header files. The outputs on which <tt>nix</tt> commands
operate are determined as follows:
* You can explicitly specify the desired outputs using the syntax <em>installable</em><tt>^</tt>*output1*<tt>,</tt>*...*<tt>,</tt>*outputN* — that is, a caret followed immediately by a comma-separated list of derivation outputs to select.
For installables specified as @ref "flake-output-attribute" "Flake output attributes" or @ref "store-path" "Store paths", the output is specified in the same argument:
For example, you can obtain the <tt>dev</tt> and <tt>static</tt> outputs of the <tt>glibc</tt> package:
@icode{console}
# nix build 'nixpkgs#glibc^dev,static'
# ls ./result-dev/include/ ./result-static/lib/
…
@endicode
and likewise, using a store path to a "drv" file to specify the derivation:
@icode{console}
# nix build '/nix/store/gzaflydcr6sb3567hap9q6srzx8ggdgg-glibc-2.33-78.drv^dev,static'
…
@endicode
For <tt>--expr</tt> and <tt>-f</tt>/<tt>--file</tt>, the derivation output is specified as part of the attribute path:
@icode{console}
$ nix build -f '<nixpkgs>' 'glibc^dev,static'
$ nix build --impure --expr 'import <nixpkgs> { }' 'glibc^dev,static'
@endicode
This syntax is the same even if the actual attribute path is empty:
@icode{console}
$ nix build --impure --expr 'let pkgs = import <nixpkgs> { }; in pkgs.glibc' '^dev,static'
@endicode
* You can also specify that <em>all</em> outputs should be used using the
syntax <em>installable</em><tt>^*</tt>. For example, the following shows the size
of all outputs of the <tt>glibc</tt> package in the binary cache:
@icode{console}
# 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
@endicode
and likewise, using a store path to a "drv" file to specify the derivation:
@icode{console}
# nix path-info --closure-size '/nix/store/gzaflydcr6sb3567hap9q6srzx8ggdgg-glibc-2.33-78.drv^*'
…
@endicode
* If you didn't specify the desired outputs, but the derivation has an
attribute <tt>meta.outputsToInstall</tt>, Nix will use those outputs. For
example, since the package <tt>nixpkgs\#libxml2</tt> has this attribute:
@icode{console}
# nix eval 'nixpkgs#libxml2.meta.outputsToInstall'
[ "bin" "man" ]
@endicode
a command like <tt>nix shell nixpkgs\#libxml2</tt> will provide only those
two outputs by default.
Note that a [store derivation] (given by its <tt>.drv</tt> file store path) doesn't have
any attributes like <tt>meta</tt>, and thus this case doesn't apply to it.
* Otherwise, Nix will use all outputs of the derivation.
@section autotoc_md100 Nix stores
Most <tt>nix</tt> subcommands operate on a <em>Nix store</em>.
The various store types are documented in the
@ref "@docroot@/store/types/index.md" "Store Types"
section of the manual.
The same information is also available from the @ref "./nix3-help-stores.md" "nix help-stores
" command.
@section autotoc_md101 Shebang interpreter
The <tt>nix</tt> command can be used as a <tt>\#!</tt> interpreter.
Arguments to Nix can be passed on subsequent lines in the script.
Verbatim strings may be passed in double backtick (<tt>``</tt>) quotes.
Sequences of <em>n</em> backticks of 3 or longer are parsed as <em>n-1</em> literal backticks.
A single space before the closing <tt>``</tt> is ignored if present.
<tt>--file</tt> and <tt>--expr</tt> resolve relative paths based on the script location.
Examples:
@icode
#!/usr/bin/env nix
#! nix shell --file ``<nixpkgs>`` hello cowsay --command bash
hello | cowsay
@endicode
or with <strong>flakes</strong>:
@icode
#!/usr/bin/env nix
#! nix shell nixpkgs#bash nixpkgs#hello nixpkgs#cowsay --command bash
hello | cowsay
@endicode
or with an <strong>expression</strong>:
@icode{bash}
#! /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.
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
)""