treewide/nixos: remove with lib; part 5

[Stunkymonkey]

Description of changes

part of #208242

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]

Felix, is this with the new script or old?

[Stunkymonkey]

@philiptaron this was done with the new one. But the commit messages are not yet improved...

[philiptaron]

If we split this part 5 and the part 6 into groups of 50, I think I can reviews them all this coming week.

[philiptaron]

Whew, it's at zero defects this time.

[Stunkymonkey]

@philiptaron can we agree, that when you find a single defect in this kind of MRs -> mention it an abort any further reading?

just to safe you some time

[philiptaron]

@philiptaron can we agree, that when you find a single defect in this kind of MRs -> mention it an abort any further reading?

Sure, I can do that. Now that we have a script that ought to reliably yield zero defects that's a sane default.

[philiptaron]

No error reports the next day. Looking at tranche 6 now.

[K900]

#363775

How many of these do we need to explode to realize that we need better testing? I believe we're currently at 4/5.

[philiptaron]

@K900, the PRs done with the old sed-based script were definitely too low quality. We paused any merges of changes produced with that tool.

So please do not count those initial failures as being part of this one.

The new script that Felix uses in this PR is subject to time-of-script-run issues, where unless there is a merge conflict (not guaranteed) things like #363775 are possible.

On a personal note, I find the characterization of one quickly fixed defect across ~1,000 LOC change as an "explosion" to be unkind. You yourself have made many defects, merged them to master, then fixed them. That's good. Please don't harangue others for behavior you engage in.

I'm all ears for a testing strategy that produces fewer defects, that is actually able to be run by humans without a build lab. It's certainly not my intention to check in code that causes defects.

[Mic92]

@philiptaron I think you can run this:

nix-eval-jobs --workers <replaceme> --force-recurse --flake .#legacyPackages.x86_64-linux.nixosTests --force-recurse

Replace replaceme with: maximum_ram_usage / 4GB

It's not perfect because it won't cover modules without tests into account, but it is a start.

[Stunkymonkey]

i can confirm my script completely ignores the line in #363768.

We should have run nix-build . -A nixosTests.redis to prevent this. Are there any other commands that are more "leightweight" to detect this? i tried nix-instantiate --parse but no success.

[Mic92]

Not sure if light-weight alternatives give you decent coverage. Our nix-community x86 machine might be a good target to run this for a bit longer.