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

Many nix subcommands operate on one or more installables. These are command line arguments that represent something that can be built in the Nix store. Here are the recognised types of installables:

Flake output attributes: 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 defaultPackage.system (e.g. defaultPackage.x86_64-linux), 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.
Store paths: /nix/store/v5sv61sszx301i0x6xysaqzla09nksnd-hello-2.10

These are paths inside the Nix store, or symlinks that resolve to a path in the Nix store.
Store derivations: /nix/store/p7gp6lxdg32h4ka1q398wd9r2zkbbz2v-hello-2.10.drv

Store derivations are store paths with extension .drv and are a low-level representation of a build-time dependency graph used internally by Nix. By default, if you pass a store derivation to a nix subcommand, it will operate on the output paths of the derivation. For example, nix path-info prints information about the output paths:
```
# 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 --derivation flag.
Nix attributes: --file /path/to/nixpkgs hello

When the -f / --file path option is given, installables are interpreted as attribute paths referencing a value returned by evaluating the Nix file path.
Nix expressions: --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>).

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.

Nix stores

Most nix subcommands operate on a Nix store.

TODO: list store types, options

)""

5.2 KiB Raw Blame History

Examples

Description

Installables

Nix stores

5.2 KiB

Raw Blame History