status
this chapter is in active development
expect live edits and rapid iteration (except for when i am really busy with other stuff) while this material is written.
why nix exists, what it actually solves, and how this series approaches it.
“make it work, make it right, make it reproducible”
nix is a package manager and build system where builds are pure: explicit inputs, no ambient environment, output stored by content hash in /nix/store. two packages that need different versions of a dependency each get their own path. nothing overwrites anything.
the model is simple once you see it whole. the hard part is seeing it in the right order: the store before the language, the language before derivations, derivations before flakes.
this series goes from the bottom up.
the order matters. most tutorials start with nix shell or nix develop and let you cargo-cult from there. this one starts with the store (why it works, how paths are computed, what builds are isolated from) before touching the language or the tooling. by the time flakes come up, you'll know why they were needed.
you do not need any prior nix experience. knowing your way around a terminal and having bumped into dependency problems before is enough.
the nix store is where everything lives: every package, every derivation, every source archive, addressed by content hash. nothing overwrites anything.
references and closures covers how nix tracks what depends on what, and what that means for garbage collection.
the nix language goes through attribute sets, functions, let, with, and lazy evaluation. it was designed for one job and some of the sharp edges show.
derivations looks at the .drv file directly, before any helper framework wraps it.
nixpkgs is the world's largest package collection. the patterns matter: callPackage, overlays, overrides.
flakes opens with the history (channels, nix-env, NIX_PATH, and why none of it reproduced reliably) then covers what changed: pinned inputs, lock files, pure evaluation.
the nix command covers nix build, nix shell, nix develop, nix store, and the rest of the unified cli that replaced the old fragmented tooling.
development environments is where most people first get value out of nix: per-project shells without docker or version managers.
home manager extends that to your whole user environment: dotfiles, packages, and config declared as nix expressions.
nixos is your entire operating system declared as a nix expression.
packaging real software is about writing derivations from scratch: language-specific builders, patches, and handling things that don't fit the standard model.
flake patterns covers flake-parts and the module system applied to flake outputs, for flakes that have grown past a single file.