make descriptions of each installable type an own subsection

this is easier to edit, provides anchors for free, and renders correctly
on the terminal without additional effort.
This commit is contained in:
Valentin Gagarin 2023-01-19 12:39:07 +01:00
parent 0507462c06
commit 1e87d5f1ea

View file

@ -50,23 +50,31 @@ manual](https://nixos.org/manual/nix/stable/).
Many `nix` subcommands operate on one or more *installables*. These are Many `nix` subcommands operate on one or more *installables*. These are
command line arguments that represent something that can be built in command line arguments that represent something that can be built in
the Nix store. Here are the recognised types of installables: the Nix store.
* **Flake output attributes**: `nixpkgs#hello` For most commands, if no installable is specified, the default is `.`,
i.e. Nix will operate on the default flake output attribute of the
flake in the current directory.
These have the form *flakeref*[`#`*attrpath*], where *flakeref* is a Here are the recognised types of installables:
flake reference and *attrpath* is an optional attribute path. For
more information on flakes, see [the `nix flake` manual
page](./nix3-flake.md). 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 ## Flake output attributes
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 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](./nix3-flake.md). 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]` `git+file://[GIT_REPO_ROOT]?dir=[RELATIVE_FLAKE_DIR_PATH]`
where `GIT_REPO_ROOT` is the path to the root of the git repository, 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 and `RELATIVE_FLAKE_DIR_PATH` is the path (relative to the directory
@ -89,7 +97,7 @@ the Nix store. Here are the recognised types of installables:
Then `/foo/bar/baz/blah` will resolve to `git+file:///foo/bar?dir=baz` 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 - 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 `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). 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. If no such directory exists, then Nix will error-out.
@ -97,53 +105,57 @@ the Nix store. Here are the recognised types of installables:
For example, if `/foo/bar/flake.nix` exists, then `/foo/bar/baz/` will resolve to For example, if `/foo/bar/flake.nix` exists, then `/foo/bar/baz/` will resolve to
`path:/foo/bar` `path:/foo/bar`
If *attrpath* is omitted, Nix tries some default values; for most If *attrpath* is omitted, Nix tries some default values; for most
subcommands, the default is `packages.`*system*`.default` subcommands, the default is `packages.`*system*`.default`
(e.g. `packages.x86_64-linux.default`), but some subcommands have (e.g. `packages.x86_64-linux.default`), but some subcommands have
other defaults. If *attrpath* *is* specified, *attrpath* is other defaults. If *attrpath* *is* specified, *attrpath* is
interpreted as relative to one or more prefixes; for most interpreted as relative to one or more prefixes; for most
subcommands, these are `packages.`*system*, subcommands, these are `packages.`*system*,
`legacyPackages.*system*` and the empty prefix. Thus, on `legacyPackages.*system*` and the empty prefix. Thus, on
`x86_64-linux` `nix build nixpkgs#hello` will try to build the `x86_64-linux` `nix build nixpkgs#hello` will try to build the
attributes `packages.x86_64-linux.hello`, attributes `packages.x86_64-linux.hello`,
`legacyPackages.x86_64-linux.hello` and `hello`. `legacyPackages.x86_64-linux.hello` and `hello`.
* **Store paths**: `/nix/store/v5sv61sszx301i0x6xysaqzla09nksnd-hello-2.10` ## Store paths
These are paths inside the Nix store, or symlinks that resolve to a Example: `/nix/store/v5sv61sszx301i0x6xysaqzla09nksnd-hello-2.10`
path in the Nix store.
* **Store derivations**: `/nix/store/p7gp6lxdg32h4ka1q398wd9r2zkbbz2v-hello-2.10.drv` These are paths inside the Nix store, or symlinks that resolve to a
path in the Nix store.
By default, if you pass a [store derivation] path to a `nix` subcommand, the command will operate on the [output path]s of the derivation. ## Store derivations
[output path]: ../../glossary.md#gloss-output-path Example: `/nix/store/p7gp6lxdg32h4ka1q398wd9r2zkbbz2v-hello-2.10.drv`
For example, `nix path-info` prints information about the output paths: By default, if you pass a [store derivation] path to a `nix` subcommand, the command will operate on the [output path]s of the derivation.
```console [output path]: ../../glossary.md#gloss-output-path
# nix path-info --json /nix/store/p7gp6lxdg32h4ka1q398wd9r2zkbbz2v-hello-2.10.drv
[{"path":"/nix/store/v5sv61sszx301i0x6xysaqzla09nksnd-hello-2.10",…}]
```
If you want to operate on the store derivation itself, pass the For example, `nix path-info` prints information about the output paths:
`--derivation` flag.
* **Nix attributes**: `--file /path/to/nixpkgs hello` ```console
# nix path-info --json /nix/store/p7gp6lxdg32h4ka1q398wd9r2zkbbz2v-hello-2.10.drv
[{"path":"/nix/store/v5sv61sszx301i0x6xysaqzla09nksnd-hello-2.10",…}]
```
When the `-f` / `--file` *path* option is given, installables are If you want to operate on the store derivation itself, pass the
interpreted as attribute paths referencing a value returned by `--derivation` flag.
evaluating the Nix file *path*.
* **Nix expressions**: `--expr '(import <nixpkgs> {}).hello.overrideDerivation (prev: { name = "my-hello"; })'`. ## Nix attributes
When the `--expr` option is given, all installables are interpreted Example: `--file /path/to/nixpkgs hello`
as Nix expressions. You may need to specify `--impure` if the
expression references impure inputs (such as `<nixpkgs>`).
For most commands, if no installable is specified, the default is `.`, When the `-f` / `--file` *path* option is given, installables are
i.e. Nix will operate on the default flake output attribute of the interpreted as attribute paths referencing a value returned by
flake in the current directory. evaluating the Nix file *path*.
## Nix expressions
Example: `--expr '(import <nixpkgs> {}).hello.overrideDerivation (prev: { name = "my-hello"; })'`.
When the `--expr` option is given, all installables are interpreted
as Nix expressions. You may need to specify `--impure` if the
expression references impure inputs (such as `<nixpkgs>`).
## Derivation output selection ## Derivation output selection