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.
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.
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?
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
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 Also it’s sometimes problematic that the chart’s x-axis is stamp of the build run, so ordering may not always be correct.
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 ?
