3.3 Deriving the dev shell from the package definition

Listing 15 packages in a shell.nix works, but it leaves you with two descriptions of your project: what developers use, and what CI and production actually build. This lesson flips the order. You describe the package build once, and Nix hands you the matching dev shell for free, so nix-shell and nix-build are guaranteed to agree.

In this video

• Why "works in my shell, fails in CI" happens, and how the build sandbox removes the guesswork
• Turning the tmux shell definition into a real package with stdenv.mkDerivation: the handful of attributes it needs
• What mkDerivation figures out on its own about a configure and make based project, and the one step it cannot detect
• The fallback trick that makes nix-shell work with no shell.nix in the repo at all
• Running the exact same nix-build your CI runs, before you commit anything

After this lesson

You can build a small autotools project as a Nix package and drop into its dev shell from the same file, with one single source of truth for developers, CI, and production.