Python: Add overrideAttrs attribute aliasing overridePythonAttrs

[adisbladis]

Motivation for this change

This will make lib.makeOverridable use overridePythonAttrs by default.

Overriding Python packages has some surprising properties unless you use overridePythonAttrs and it can be incredibly frustrating to try and find out why that is.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[adisbladis]

@FRidh What kind of tests do you have in mind?

[FRidh]

Testing that buildPythonPackage is indeed invoked again. One way to assert this is by adding to propagatedBuildInputs and testing it has an affect on requiredPythonModules, which serves as input to python.buildEnv.

[FRidh]

cc @alyssais because of #46842.

That discussion was already a year and a half ago...time flies.

[adisbladis]

@FRidh I added a test. Since it's not actually building anything but only asserts attributes I made a new type of test.

[FRidh]

@GrahamcOfBorg build python2.tests python3.tests python38.tests

[FRidh]

@GrahamcOfBorg build pypy2.tests pypy3.tests

[FRidh]

Let's wait a bit with merging this.

[alyssais]

@FRidh yiu don’t think this needs an RFC any more?

[FRidh]

Right, I wrote that. I do think it is best we standardize interfaces like these and I see you asked matthewbauer at the time to help with it. Let's write a small RFC and see where that takes us.

[FRidh]

RFC proposal #46842 (comment)

[infinisil]

Not sure about this, because we already have a bunch of override mechanisms which all work slightly differently. And by doing this it gets even more complex because it mixes ones name with anothers behavior. But then again, python packages accept pretty much all arguments of mkDerivation and juts forward them, so .overrideAttrs would mostly still behave the same for mkDerivation argument overrides. But still, I feel like this is going in the wrong direction of mixing concepts.

[adisbladis]

Closing, see NixOS/rfcs#67.