Event language
UI language
<p></p><p>Nix offers declarative, reproducible builds but this can’t happen if you rely on a mutable provenance — hence the need for “input pinning”. </p><p>Prior art of niv & npins ‘solved’ with a lockfile operated via a CLI application. Experimental Flakes did the same, but with a manifest file however also mixes in project structure concerns leading to some good but some poor patterns. All currents options have underlying & unsolved limitations when you step outside the narrow scope of how they expect your project — & your inputs sources — are set up. </p><p>Nixtamal takes a fuller, flexible approach to these shortcomings. It focuses strictly on input pinning, using a declarative manifest to make decisions explicit: what is pinned, how “freshness” is determined, which patches are applied, & where mirrors fit into the model. By depending on Nixpkgs rather than Nix’s builtins, Nixtamal can reuse richer fetchers & support VCSs & workflows that Flakes & other tools cannot, without re-implementing the toolchain inside the sandbox. </p><p>This talk compares existing pinning approaches — including what inputs.*.follows can/cannot express — & shows what a manifest-based model enables in practice. Attendees will come away with a clearer mental model of input pinning in the Nix design space, why mirrors + user-defined freshness matter, & when separating pinning from composition leads to simpler & more robust Nix workflows.</p><br><p></p>
