Disallow new uses of `overrideAttrs`

[RossSmyth]

https://github.com/NixOS/nixpkgs/blob/9aa8fa66b104a46b7be979192b1fee4a11220d8d/pkgs/README.md#overrideattrs-and-overridepythonattrs

Rules are fake without automation enforcing them.

[MattSturgeon]

I agree, we should prefer enforcement and linting over policy and rules.

However, I also questioned whether this particular rule (or guidance?) has been fully thought through. I believe there are still some legitimate use cases for overrides in nixpkgs, even if many current uses are not legitimate.

One possible example is update scripts that produce a generated package, which the "actual" package extends using overrides. nixfmt is packaged this way, using a cabal2nix update script.

Another example might be build helpers, which often makes careful use of overrideAttrs internally. Or passthru tests, which often use an overridden variant of the package under test (finalAttrs.finalPackage.overrideAttrs).

IIUC, the current guidance is focused on scenarios where one person maintains a package and another person maintains an override of it. The premise being that changes to the base package can silently break the overridden package, without either maintainer noticing; especially if the override is not careful or is relying on implementation details of the base package.

This is valid, and there are plenty of scenarios in which a better solution can be found than defaulting to overrides.

My first point is that some override are maintained in close proximity to the base package, like the "generated package" example above. I don't think the current guidance has considered this pattern.

My second point is that, sometimes, it is also appropriate to use "safe" overrides; perhaps extending passthru or configuring documented "public API" attributes. Even in an "override at a distance" scenario.

TL;DR: I'm skeptical of blanket "overrides bad" guidance because I think the reality is more nuanced and situational.

(Sorry for the rambling essay)