Nix 2.5.0 released


I’m pleased to announce the availability of Nix 2.5.0. It is available from NixOS - Getting Nix / NixOS.

Here are the release notes:

  • The garbage collector no longer blocks new builds, so the message waiting for the big garbage collector lock... is a thing of the past.

  • Binary cache stores now have a setting compression-level.

  • nix develop now has a flag --unpack to run unpackPhase.

  • Lists can now be compared lexicographically using the < operator.

  • New built-in function: builtins.groupBy, with the same functionality as Nixpkgs’ lib.groupBy, but faster.

  • nix repl now has a :log command.

The next release is scheduled for 2022-01-24.

Thank you to all the contributors!



First, thank you for Nix 2.5!

Just, as I see a new built-in, I’m curious: is there any RFC that
described this addition to the language? Given that the RFC repo readme
explicitly mentions “Any semantic or syntactic change to the language
that is not a bug fix” and “Introduction of new interfaces or functions”
as requiring an RFC, I think a new built-in would fit the bill.

My thinking is that just dumping functions from lib into builtins to
make them faster may be a good short-term solution to slowness, but may
be a long-term hindrance by forcing nix to keep backwards-compatibility
with that forever.

So I don’t want to debate this specific addition here, but do you know
of any RFC or framework RFC that would clarify which functions should be
made into built-ins and which ones should not? And if there is currently
none, would it be possible to have one before the next addition of a
built-in, in order to avoid built-in proliferation issues?

(cc @infinisil as you appear to have made the initial PR)


The RFC process is for “when one intends to make “substantial” changes to the Nix ecosystem”, which in my opinion doesn’t apply to adding utility functions like groupBy (and I don’t think we’ve ever had an RFC about adding a builtin function). Having said that, it would be good to have some written rule about when it is appropriate to add builtin functions.


@edolstra I’ve noticed that the most recent builtin fetchers are usually exposing functionality that was added for flakes, am I correct?

Yes (if you mean builtins.fetchTree), but I think it requires the flakes experimental feature to be enabled.

I’m also talking about fetchGit and friends

Nixpkgs still has Nix 2.4. Why can’t I find a PR on nixpkgs for Nix 2.5?


There is one now: nix: 2.4 -> 2.5.1 by roberth · Pull Request #151419 · NixOS/nixpkgs · GitHub


Am I mistaken, but is /nix/store/trash a thing of the past as well? Is that what the “big lock” was?

1 Like

The trash directory existed to reduce the time window during which the garbage collector had to hold the global GC lock (since moving a big store path to trash is quick, while deleting it may be slow). Now that the collector is non-blocking, this is no longer necessary.

Hosted by Flying Circus.