A couple of weeks ago Nix 2.4 was released. This was the first release in more than two years. More than 195 individuals contributed to this release. Since Tweag is the biggest contributor to the Nix project, I’d like to highlight some of the features that Tweag has worked on.
Flakes are a new format to package Nix-based projects in a more
discoverable, composable, consistent and reproducible way. A flake is
just a repository or tarball containing a file named
specifies dependencies on other flakes and returns any Nix assets such
as packages, Nixpkgs overlays, NixOS modules or CI tests.
You can read more about flakes in the following blog posts:
- Nix Flakes, Part 1: An introduction and tutorial
- Nix Flakes, Part 2: Evaluation caching
- Nix Flakes, Part 3: Managing NixOS systems
The development of flakes was sponsored by Target Corporation and Tweag.
Nix’s store can now be content-addressed, meaning that the hash component of a store path is the hash of the path’s contents. Previously Nix could only build input-addressed store paths, where the hash is computed from the derivation dependency graph. Content-addressing allows deduplication, early cutoff in build systems, and unprivileged closure copying.
- Towards a content-addressed model for Nix
- Self-references in a content-addressed Nix
- Derivation outputs in a content-addressed world
- Implementing a content-addressed Nix
CAS was developed by Tweag and Obsidian Systems, who were supported by an IPFS Grant.
The Nix command line interface (CLI) - commands such as
nix-build - is pretty old and doesn’t provide a very good user
experience. A couple of years ago we started working on a new CLI: a
nix command to replace the
nix-* commands that aims to be
more modern, consistent, discoverable and pleasant to use.
However, work on the new CLI had stalled somewhat because we didn’t
have a discoverable packaging mechanism for Nix projects. Thanks to
flakes, we now do! As a result, in Nix 2.4, the
nix command has seen
a lot of work and is now almost at feature parity with the old CLI. It
is centered around flakes; for example, a command like
> nix run nixpkgs#hello
runs the hello application from the
Most of the work on the new CLI was done by Tweag. We organized a Nix UX team to review the state of the Nix user experience and plan improvements. A major result of the UX team is a set of CLI guidelines for the Nix project. More UX improvements are coming up, including an interactive progress indicator.
The previous Nix release (2.3) was in September 2019. Having a 2-year
gap between releases is something we want to avoid in the future,
since it’s bad for both contributors and users that there is an
unbounded amount of time before a new feature shows up in a stable
release. The thing that has historically caused long gaps between Nix
releases is new experimental features landing in master that we
weren’t quite sure about, and doing a new release meant having to
support these features indefinitely. However, Nix 2.4 introduces a
mechanism to mark features as experimental, requiring them to be
enabled explicitly on the command line or in the
configuration file. Thanks to this, we can merge experimental features
in a way that still allows them to be changed or removed, while still
getting feedback from adventurous users.
Therefore, starting with Nix 2.4, we have switched to a 6-weekly release schedule, meaning that we do a new release every 6 weeks. In fact, Nix 2.5.0 was already released a few days ago!
A very old annoyance with large Nix stores (such as CI systems) is that garbage collection can take a long time, and during that time, you couldn’t start new builds. Instead you would get the infamous message
waiting for the big garbage collector lock...
Nix 2.5 has a new garbage collector that makes this a thing of the past: the collector no longer prevents new builds from proceeding. The development of the new collector was sponsored by Flox.