Nix Package Manager
Nix can look like just another way to install command-line tools. That is the shallow end. The deeper idea is that packages, development shells, and even user or system configuration can be described as data and rebuilt later.
The learning path is easier if each step answers one practical need.
A Progressive Path
| Stage | What you learn |
|---|---|
| Install Nix | Get the package manager available on your machine. |
| Install global packages | Use Nix like a package manager for tools you want on your path. |
Use nix-shell |
Create temporary local environments for a project or experiment. |
| Learn the Nix language | Read and write the expressions that describe packages and environments. |
| Use profiles | Manage installed packages through profile-based commands such as nix profile install. |
| Try Nix flakes | Move project outputs into a more explicit, reproducible project shape. |
| Add Home Manager | Manage user-level programs and dotfiles declaratively. |
| Explore NixOS | Move from user environments toward full system configuration. |
| Write derivations | Describe custom build tasks directly. |
The order matters because Nix combines several ideas. Using it only as a global installer does not explain why people use it for reproducible project environments. Jumping straight to full system configuration can hide the smaller pieces.
The Useful Mental Model
Nix work usually moves through these questions:
- What package or tool should exist?
- In which environment should it be visible?
- Is that environment temporary, user-wide, project-specific, or system-wide?
- Is the description reproducible enough for another machine or CI job?
That model also explains why Nix appears in release workflows. A release can publish artifacts, and it can also expose a Nix installation path or flake output for users who consume software that way.