While Nix is typically called a “package manager”, I recommend thinking of it more like a build system.
And flakes are like blueprints to feed into that build system.
A flake can contain a number “outputs” that can be build, this can be a package, a system configuration, a module for a system configuration, a development environment and much more.
But be aware that nix is very picky and will only accept flakes if it can (typically) guarantee that it will always build the same thing, on every platform, at any time.
That’s why you have to specify external “inputs” like system libraries, git repos or files, if you want to use these within your flake.
After running your flake for the first time, nix will generate a flake.lock file for you.
This file contains all used “inputs”, pinned to the specific version/hash used, so that builds in the future will be executed on exactly the same inputs.
And while we’re at it, I should explain something: A flake is a directory, containing a “flake.nix” file, not the file itself. Since other aspects are also part of the “flake” you build, like the lockfile or version control system (if a VCS exists, the flake will only see files that are tracked by it).
This makes flakes very powerful, since they allow nix to be used in a very modular manner.
Here’s an example:
If you’d want nix to build and run a little fetcher I’ve written, you could just type:
This would make nix fetch the flake from sourcehut, build all “inputs” (these are typically prebuild and pulled from cache.nixos.org), compile the rust-code that is within the flake, add the output package to the local /nix/store and run it.
Here’s a (hopefully) simple breakdown on flakes:
While Nix is typically called a “package manager”, I recommend thinking of it more like a build system.
And flakes are like blueprints to feed into that build system.
A flake can contain a number “outputs” that can be build, this can be a package, a system configuration, a module for a system configuration, a development environment and much more.
But be aware that nix is very picky and will only accept flakes if it can (typically) guarantee that it will always build the same thing, on every platform, at any time.
That’s why you have to specify external “inputs” like system libraries, git repos or files, if you want to use these within your flake.
After running your flake for the first time, nix will generate a flake.lock file for you. This file contains all used “inputs”, pinned to the specific version/hash used, so that builds in the future will be executed on exactly the same inputs.
And while we’re at it, I should explain something: A flake is a directory, containing a “flake.nix” file, not the file itself. Since other aspects are also part of the “flake” you build, like the lockfile or version control system (if a VCS exists, the flake will only see files that are tracked by it).
This makes flakes very powerful, since they allow nix to be used in a very modular manner.
Here’s an example: If you’d want nix to build and run a little fetcher I’ve written, you could just type:
nix run sourcehut:~sntx/nx-fetch(c.f. https://git.sr.ht/~sntx/nx-fetch )This would make nix fetch the flake from sourcehut, build all “inputs” (these are typically prebuild and pulled from cache.nixos.org), compile the rust-code that is within the flake, add the output package to the local /nix/store and run it.
Edit 1: Fixed typo