treewide/nixos: remove with lib; part 6

[Stunkymonkey]

Description of changes

part of #208242

the CI forces me to make nixfmt commits as well.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[philiptaron]

Two commits to drop. I didn't find any defects in the code itself. The new script is substantially higher quality.

@Stunkymonkey, when you drop them, please rebase on to master to so that we can try to find issues like #363775 / #363768.

Do you have a root cause for why that issue occurred? Was it a time-of-script-run-to-time-of-merge problem?

[philiptaron]

In fact, the script just needs to run from scratch considering the set of merge conflicts. I'm assuming this is due to a tree-wide format happening.

150 commits is too much for me to review. Let's drop it to 50.

[philiptaron]

Based on my experience merging the other PRs, Felix (@Stunkymonkey), I'm going to sit it out for a while. I don't have enough confidence there are zero defects here, and I know with the new script, I'd need to actually run tests against all the modules here -- which I don't have the computing power to do, and I don't think you do either.

[Stunkymonkey]

@philiptaron i guess we should then close the remaining MRs. We will not use exactly this in the future.

[philiptaron]

@philiptaron i guess we should then close the remaining MRs. We will not use exactly this in the future.

Hold tight for one moment. I'm trying out the suggestion to use nix-eval-jobs. I don't understand its output (especially error output) yet.

[philiptaron]

So I found out a couple things:

1. Evaluating all the NixOS tests is pretty effective at finding errors the new script makes.

Here's how that works.

On master:

time NIXPKGS_ALLOW_UNFREE=1 NIXPKGS_ALLOW_INSECURE=1 NIXPKGS_ALLOW_BROKEN=1 nix-eval-jobs --workers 20 --force-recurse --impure --flake .#legacyPackages.x86_64-linux.nixosTests > ../baseline.json

Then, on the branch, rebase to the same master, then run the command, redirecting to a different file.

Then you diff them.

2. Every error has been an error of omission (the script should have changed something, but did not.)

For me as a reviewer of changes, this is pretty bad, since the failures won't show up in the diff -- they're elsewhere and have to be guessed at.

3. Every error has been under a with. This means the script is being way-laid by the same reason that we're removing these things in the first place -- they delay undefined variable errors until whatever that branch is gets evaluated, if it ever does.

Since not every module has a NixOS test, that means errors are likely to show up to real users and be quite inopportune.