• GitHub
  • Mastodon
  • Twitter
  • Slack
  • Linkedin


Nixpkgs: the big recipe book of open source

Flox Team | 2 March 2023
Nixpkgs: the big recipe book of open source

Nixpkgs is just that: the big fat recipe book of all open source. Anybody can view it, fork it, patch it, and use Nix to inspect the largest set of free software recipes in the world.

People sometimes focus on Nix the language or Nix the package manager, but it's the Nixpkgs package collection that is core to the success of Nix. But it's more than that: we can also understand Nixpkgs as a powerful tool to ensure the continued growth, transparency, and resilience of open source software, mainly because it democratizes the process of curating this software and its build instructions. It is the living library of the efforts of thousands of contributors, who both stand on the shoulders of giants (the software they're packaging) and provide the ladder for others to climb further.

Packaging universally

Today we package software for independent islands, each with their own formats, rules, languages and, until Nix, we had not found a way to build packages across the runtimes of our software archipelago. Nix allowed for packages being available on more platforms, which drew more developers in, which resulted in Nixpkgs becoming more complete, and so on in a positive feedback loop.

Nix is a cross-platform, cross-architecture package manager. If we had to design the next-generation package manager, this would probably be at the top of the requirements list, yet few package managers enable this today. Each of the teams at RedHat or Debian maintains their own packaging format and package cache, and has a fixed team of vetted contributors to keep packages secure and up to date. This results in few who effectively contribute to packaging open source projects, and do so for one of many platforms.

Scaling review

An open book of package recipes written in a common language results in another surprising effect: Nixpkgs maintains more packages than anybody with an order of magnitude fewer maintainers (1). It makes sense: since it’s a common language, people can review the packaging code for packages they don’t necessarily know intimately, which in turn leads to contributors and reviewers cycling through updates faster and providing more up-to-date packages, which reinforces the previous feedback loop from earlier.

Even if the rest of the Nix ecosystem stalled out, we’d still have this incredible resource in Nixpkgs to curate and share open source software. flox sources its packages exclusively from Nixpkgs for this (and many other) reasons. As of February 2023, there were around 6,000 contributors on the Nixpkgs repository and growing.

repology via repology.org

How flox uses Nixpkgs

flox serves packages from the Nixpkgs-flox repository, which tracks Nixpkgs branches directly. We added some functionality we wanted to see and thought others would want: semantic versioning for packages, and custom tracking of unstable, stable, and staging branches, for example.

Anybody can take the Nixpkgs collection and suit it to their needs via the Nix language, something that would be far more complex to achieve with other package managers. This ability to have total control over the packages one employs, even across different contexts, provides a flexibility and power that is hard to achieve with traditional package management methods.

How does it work?

What happens in practice when I download a package from the Nix cache? When you query for a package, the CLI creates the specification (we call it a derivation) of the package to be built. This derivation includes a hash: the summary identifier of all source code, patches, build flags, and hashes of the dependencies themselves.

With that output hash in hand, Nix the package manager just asks whether that path exists in its cache. If it does, Nix fetches the contents of the package you asked for; if it doesn't, Nix will build the package locally. We call this move substitution: creating a derivation from a Nixpkgs expression gives you all the information you need about the output of the build, so the cache can substitute a binary with that output hash if it has it. Of course, if you end up having to build the package locally, it will result in the expected output hash anyway.

Stay unstable, my friends

Nixpkgs embodies a new model for package management, and one that opens it up to more people to contribute. Providing cross-platform and cross-language packages is uniquely attractive, but it's the accessability, flexibility, and transparency that make it a pillar of open source moving forward. Because Nixpkgs unifies a broader swath of software, and makes it easy for anybody to contribute new packages and fix existing ones, it continues to grow and serve the open source community: a positive feedback loop propelling the existence of a more free and open world of software.

Ready to experience Nixpkgs for yourself? Download flox today!