Nixpkgs on paradigmatic.systems https://paradigmatic.systems/tags/nixpkgs/ Recent content in Nixpkgs on paradigmatic.systems Hugo -- gohugo.io en-us Wed, 13 Aug 2025 04:30:00 +0000 Nix: the Language, the Tool, the Package Repo, the OS https://paradigmatic.systems/posts/nix-nixpkgs-nixos/ Wed, 13 Aug 2025 04:30:00 +0000 https://paradigmatic.systems/posts/nix-nixpkgs-nixos/ <p>There&rsquo;s a lot going on in the Nix ecosystem. If you haven&rsquo;t slogged through <a href="https://edolstra.github.io/pubs/phd-thesis.pdf">the thesis</a> then it might seem downright opaque. This is my attempt at an easy explainer for newcomers.</p> <h2 id="the-tool-and-the-language">The Tool and the Language</h2> <p>Let&rsquo;s bootstrap ourselves with some circular facts.</p> <blockquote> <p>Nix is a <em>tool</em> for building (or &ldquo;packaging&rdquo;) <em>software components</em> using instructions expressed in the Nix <em>language</em>. The Nix language is even able to <a href="https://github.com/NixOS/nix/blob/master/flake.nix">package</a> the Nix tool (which is mostly written in C++), thus closing the epistemological loop.</p> There’s a lot going on in the Nix ecosystem. If you haven’t slogged through the thesis then it might seem downright opaque. This is my attempt at an easy explainer for newcomers.

The Tool and the Language

Let’s bootstrap ourselves with some circular facts.

Nix is a tool for building (or “packaging”) software components using instructions expressed in the Nix language. The Nix language is even able to package the Nix tool (which is mostly written in C++), thus closing the epistemological loop.

The language features first-class treatment of filesystem paths and URLs (to source code and tarballs, for example). Nix expressions are evaluated in a hermetic environment with no path variables and no files. All outside references get copied into content-addressed folders in the store, and marked as build-time dependencies in any derivation that gets defined. Retained runtime dependencies are calculated by scanning the actual binary for store paths.

The Build

The component is the result of realizing the derivation. That means grabbing all the store path contents and combining them in the prescribed way. Imagine you have 3 components that are build-time dependencies:

  1. A compiler
  2. Source code
  3. A bash script that uses the compiler to build the source

The derivation describes where to find these, and the (obvious) way that they fit together. The result is content-addressed with a hash based on all its dependencies, and placed in the store.

nixpkgs

It turns out this scheme is highly flexible and repeatable. nixpkgs is a repo full of Nix expressions for over 120,000 packages. You can pull any one of them into an ephemeral shell to try it out, or install it system-wide if you’re using:

NixOS

Finally, notice that “software components” could have a very broad definition. So broad, in fact, to include an entire OS with all of the installed programs and services. That’s what NixOS is: A Linux distro defined entirely in Nix and built around the /nix/store path model instead of the more usual FHS. I’ve written a bit about how the Nix module system helps encapsulate complex system recipes into simple one-liners.

All my homies use NixOS. To paraphrase from NixOS is the endgame of distrohopping :

No more configuration drift - solved ✅

“Works on my machine!” - solved ✅

Dependency Hell - solved ✅

Virtual and development environments - solved ✅

package management - solved ✅

Ready to go deeper?

To get started I highly recommend working through the tutorials at nix.dev!

]]>