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, outputs stored under hash-derived paths 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 the pieces in order: the store before the language, the language before derivations, derivations before flakes.
this series goes from the bottom up. the first arc covers the model itself: store paths, references, the language, and derivations. the later chapters build on that foundation.
the order matters. most tutorials start with nix shell or nix develop and leave the underlying model implicit. 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, each under its own hash-derived path. 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.