Nix 2.6.0 released


I’m pleased to announce the availability of Nix 2.6.0. It will be available from NixOS - Getting Nix / NixOS.

Here are the release notes:

  • The Nix CLI now searches for a flake.nix up until the root of the current Git repository or a filesystem boundary rather than just in the current directory.
  • The TOML parser used by builtins.fromTOML has been replaced by a more compliant one.
  • Added :st/:show-trace commands to nix repl, which are used to set or toggle display of error traces.
  • New builtin function builtins.zipAttrsWith with the same functionality as lib.zipAttrsWith from Nixpkgs, but much more efficient.
  • New command nix store copy-log to copy build logs from one store to another.
  • The commit-lockfile-summary option can be set to a non-empty string to override the commit summary used when commiting an updated lockfile. This may be used in conjunction with the nixConfig attribute in flake.nix to better conform to repository conventions.
  • docker run -ti nixos/nix:master will place you in the Docker container with the latest version of Nix from the master branch.

The next release is scheduled for 2022-03-07.

Thank you to all the contributors!


builtins.zipAttrsWith is also part of larger performance work done by @pennae. This should lead to faster evaluation for the users.


Great to hear! Are there any benchmarks?

I was curious myself so I ran a quick benchmark. The results seem to vary between 11% to 17% improvement. The methodology is available over here: Nix 2.6 eval improvement


Unfortunately we haven’t been tracking performance historically. Yesterday I added a Hydra job to do this - it performs some evaluations of a fixed revision of Nixpkgs/NixOS: Hydra - nix:master:metrics.nixpkgs. So in the future this will allow us to see performance changes over this.


I’m seeing (what I think is) a regression in how flake inputs are handled. I have this flake.nix and this flake.lock. I’m seeing this error (which didn’t occur with 2.5.1)

evaluating file '/nix/store/295wakpv4yc64m0hkxlb61wyqy7zj471-source/flake.nix'
error: input 'haskellNix/nixpkgs' follows a non-existent input 'nixpkgs-2111'
(use '--show-trace' to show detailed location information)

The inputs here are a bit complicated, but the idea is that I want my flake nixpkgs input to follow the haskell.nix flake nixpkgs input. That itself follows its own nixpkgs-2111 input. It seems like nix is failing on that last link in the chain. If you tell me this is something that wasn’t supposed to work then I’ll believe you and see about getting things changed up.

In the meantime, I can change my flake to follow the nixpkgs-2111 haskell.nix flake input and things should work. Oops, spoke too soon. nix still needs to fully resolve the inputs of haskell.nix and it can’t do that, so changing my own flake inputs doesn’t help.

The link for the flake.nix isn’t working, maybe Discourse is interpreting “flake.nix” as a URL?

Fixed. Not sure what happened, it has a bunch of extra parens and brackets. Thanks for pointing it out.

This does look like a bug.

In the meantime, maybe you could redeclare nixpkgs-2111 yourself and set haskellNix.inputs.nixpkgs.follows to point at it?

I’m also curious what happens if you simply redeclare nixpkgs-2111 yourself and otherwise do nothing? Maybe the bug is the follows feature now only looks it up from the root flake?

1 Like

What is this? nix help flake does not document a nixConfig attribute.

What is this? nix help flake does not document a nixConfig

Here’s its merged PR: Allow nix.conf options to be set in flake.nix by edolstra · Pull Request #4189 · NixOS/nix · GitHub

It allows overriding nix’s own settings when interacting with a flake.

1 Like

Oooh that looks very useful. I’m surprised it isn’t documented (searching the manual right now, the only references are a mention of the name in nix develop and the Nix 2.6 release notes).

I’m going to file an issue on documenting this, and I’m also inclined to file an issue on allowing for architecture-specific options too (e.g. nixConfig.x86_64-darwin.*) specifically for the benefit of extra-platforms.



architecture-specific options too (e.g. nixConfig.x86_64-darwin.*)
specifically for the benefit of extra-platforms.

That would be very useful. I might take a look at implementing it
later today - I’ll update that issue if I do. I might also sneak in some
docs before then :slight_smile:

1 Like

In principle it’s possible to run the job with all kinds of historical nix versions, though I don’t see an easy way how to make Hydra do this. And interested people can do it locally :slight_smile: Also it’s sometimes problematic that the chart’s x-axis is stamp of the build run, so ordering may not always be correct.

1 Like

related to the nixConfig, I find it weird that it describes the overrides in substituters as a warning since the flake does what it is designed for.
Is there a way to see the resulting config like nix show-config does for the system. Would a nix flake show-config that merges system and flake config make sense ?


I’m getting the same error, did you report this as a bug somewhere? Or did you find a temporary workaround to the problem?

OK, I just tried @lilyball’s suggestion, and added a nixpkgs-2111 declaration, and that seems to work:

inputs.nixpkgs-2111.url = "github:NixOS/nixpkgs/release-21.11";
inputs.haskellNix.url = "github:input-output-hk/haskell.nix";
inputs.nixpkgs.follows = "haskellNix/nixpkgs-unstable";
inputs.flake-utils.url = "github:numtide/flake-utils";
Hosted by Flying Circus.