Exploring Nix, the package manager to end all package managers
Package management as functional programming
I’ve been updating my workflow based on lessons learned from my first GIS project. One of the major developer UX problems I faced was installing and managing a GIS toolchain on my laptop based on QGIS and GDAL. I found both of those tools to be really difficult to work with in terms of managing their dependencies (especially QGIS with all its Python dependencies, a nightmare on macOS).
To solve this problem — indeed, to solve all future problems with package management —I’ve been doing a deep dive into Nix (Latin for “snow,” as in “every snowflake is unique,” a nod to Nix’s functional approach outlined below).
What is Nix?
Nix is a package manager that treats packages as functional closures, each one identified with a unique hash computed from a serialization of its contents and inputs rather than by version numbers. If an input, like source code or an upstream dependency, changes, the hashes for the package and all downstream dependencies are recalculated and the corresponding packages are regenerated. Each package has zero side effects, and packages are even defined using a functional programming language, also called Nix. Hence Nix’s tagline: “The Purely Functional Package Manager.”
Nix’s functional approach has many desirable consequences:
- Atomic rollbacks of your entire system
- The ability to install multiple versions of packages side-by-side without any possibility of conflicting dependencies
- Declarative package management
- Trivial to rebuild an entire package dependency graph on another system).
Anything that can be installed can be installed using Nix including NPM and Go packages, Ruby gems, and other dependencies that you might use in your project. Nix is furthermore platform-agnostic: it runs on any Linux distro and macOS (i.e., brew replacement). In this way, Nix can be used as a truly universal package manager.
I don’t think it’s hyperbolic to describe Nix as a revolutionary approach to package management.
Documentation is lacking
The main drawback to Nix is the lamentable state of documentation. This problem is well-known in the community and there have been sporadic attempts to address it. I believe that the main cause is how radically different Nix’s paradigm is from that of every other package manager out there, which leads to confusion. Even Eelco Dostra’s PhD thesis, the foundational document for Nix, has semantic ambiguities in its description of core concepts. Despite this, Nix is widely used in production by heavy hitters like Mozilla.
I’m a hardcore stickler for precise terminology and good documentation. As such, I’ve been contributing to Nix to update its documentation. I’ve also been collecting notes with the ambition to write a Nix book.
I’d love to hear from you about your package management needs
What are some of your needs from a package manager? Are there any complicated or problematic package management workflows that could use a silver bullet? I’d like to help others out with thinking about how Nix could help their development process.
