treewide: remove unused with statements from maintainer lists

[Mic92]

$ find -type f -name '*.nix' -print0 | xargs -P "$(nproc)" -0 sed -i \
  -e 's!with lib.maintainers; \[ *\];![ ];!' \
  -e 's!with maintainers; \[ *\];![ ];!'

nixf-tidy complaints now about empty maintainers set.

Description of changes

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.

[nixf-tidy-review]

✅ Looks good!

[Aleksanaa]

Thanks! Btw there's a : after your commit message, and better to use treewide instead of tree-wide in case someone is writing a script to filter commit history or something

[Mic92]

Thanks! Btw there's a : after your commit message, and better to use treewide instead of tree-wide in case someone is writing a script to filter commit history or something

Done

[Aleksanaa]

I'll revisit after 1 hour

[piegamesde]

What's the value of removing these besides "shush the linter"? Given that we want packages ideally to have maintainers anyways, I'd argue that keeping these around might be worthwhile? They probably also don't hurt performance, or at the very least could easily be optimized away to have no performance impact.

I'd argue that the linter is wrong to complain about cases like these, and should distinguish from other cases I'd consider as valid, like unused with lib; for example. (Specifically, I'd draw the line at "an unused with is fine if it's scoped only to an empty list")

[SuperSandro2000]

Just found another PR where the linter was a bit on the annoying side https://github.com/NixOS/nixpkgs/pull/331017/files#diff-d6928320a2c1b49a1351902a0e9683ed7f05d63fe6cdef002e4c8d365d322c13R7-R11