4.5 How Nix finds your runtime dependencies

Building mini-hello needed a compiler, GNU Make and coreutils. Running the finished binary needs almost none of that. This lesson shows how the Nix store keeps two different dependency trees for every package, build time and runtime, and how Nix computes the runtime closure without you declaring it anywhere.

In this video

• nix-store --query --tree on the output path versus the derivation path: two very different trees for the same package, and what each one is for
• The trick Nix uses to detect runtime dependencies inside your binaries, and why a store path can never end up there by accident
• Exploring what makes a package big with nix-tree, and tracing who pulled in an unwanted dependency with nix-why-depends
• Comparing two builds with nix-diff when an image suddenly grew
• Copying a runtime closure to another machine with nix copy, and why that covers most of what people use Docker images for

After this lesson

You can list exactly what a package needs to build and what it needs to run, answer CVE and image size questions straight from the dependency tree, and deploy an application to another machine without containers.