The pushing of nix 2.4 to nixpkgs-unstable has been a very unpleasant surprise. A lot of the sparkle of using Nix and NixOS has evaporated for me in the last couple days trying to sort the issues created by this update. Surprisingly, I wasn’t able to find anyone else who had the same problems as me.
nix search has been trashed. Before, it was fast and simple to use, now it is unexpectedly gated behind the experimental-features config option, is far slower, has noisier output and, more outrageously, has a different interface that, when you use it as before, gives you an incomprehensible error message, and is not mentioned anywhere in release notes besides “We have changed the nix command”. Even if all of the subcommands of nix are subject to change, prior warning would still have been nice because people are actually using it daily.
Besides, the decision to make the nix command error out by default is really poor. If the idea is to warn people that the program may change, a warning would have sufficed, instead of breaking the command where it worked before. Anyway, nix search was once stable, right? Why make a stable component unstable? That doesn’t instil trust in the stability of anything.
Meanwhile, it’s clear that the changes to nix search are about making it flake aware, especially since it also requires the flake experimental-feature flag. Flakes are definitely a good idea, but it appears clear that they are still considered unstable, which begs the question; was it really a good idea to include an unstable feature in a stable release? An unstable feature which is now required to use a formerly stable function?
Anyway, now that flakes are practically part of the core of using Nix, the stance towards whether you should move everything to flakes is unclear, especially for system configurations. It’s on this point that flakes seem to have a big theoretical hole. They are evaluated by default in pure mode and to turn that off, you need to remember to specify --impure every time. However system configurations are never entirely pure - they rely on state that you create when you partition the disk and the state that the inherently stateful computer gives to nixos-generate-config. As well purity means its more difficult to just add configuration to the system evaluation that you might not want to save forever.
As an example, my NixOS configuration tracked using git https://github.com/linabeee/nixos doesn’t track configuration.nix or hardware-configuration.nix, which I keep specific to the current installation. Now flakes could actually work with this setup, except I have /etc/nixos as a git repository, and when Nix sees a git repo it, as far as i can tell, unnecessarily, considers the flake a git repo… and then doesn’t copy untracked files into the store, breaking everything. Frankly, I would hazard a guess that my use case just hasn’t been thought of. I could probably fix it myself, but I would say that it would have to be an attribute of the flake input set that forces nix to ignore the git repository, to not be annoying. Since that would change the schema of flakes, I’m unlikely to want to bother because I can imagine that I would be stepping on toes at that point.
The thing is that the release notes for what will become NixOS 21.11 barely mention flakes at all, so I’m hazarding a guess that it’s a signal that flakes aren’t ready for everyone to move their configs to flakes. On the other hand I wonder if the NixOS release people knew that Nix was about to do a new stable release and they’ve been caught off guard as much as me? nixos-generate-config doesn’t seem to have changed, so it doesn’t seem like there’s a blessed solution to this problem yet.
Anyway, for these reasons I have had to set nix.package = pkgs.nix_2_3 which is sad, because the new error messages are genuinely really nice, and make fixing syntax problems a lot easier. But I really do use nix search a lot, and it’s just not usable in it’s state under Nix 2.4, besides all of the other problems with flakes.