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

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.

cc @alyssais because of #46842.

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

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

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

@GrahamcOfBorg build pypy2.tests pypy3.tests

Let's wait a bit with merging this.

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

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.

RFC proposal #46842 (comment)

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.

Closing, see NixOS/rfcs#67.