This implementation fixes the fixed point arguments taken by mkPython* before passing down instead of leaving it to stdenv.mkDerivation. This makes the semantics completely different from that provided by stdenv.mkDerivation or overrideAttrs -- The finalAttrs here will be that of <pkg>.overridePythonAttrs (finalAttrs: previousAttrs: { }) (if we add such support) instead of <pkg>.overrideAttrs (finalAttrs: previousAttrs: { }).

One significant drawback is the lack of finalAttrs.finalPackage. While we can also re-implement the finalPackage here, that would make us depend more on custom overriders like overridePythonAttrs.

Update:

As @TomaSajt suggests, it's not even something like overridePythonAttrs (finalAttrs: previousAttrs: { }), since the finalAttrs here doesn't get updated after overriding.

As @ShamrockLee said, this is just a shorthad for lib.fix. Just using lib.fix is, IMO, perfectly acceptable if you don't want to use rec

I tried to avoid awful diffs, but... here we go. Rewritten everything to pass down finalAttrs to stdenv.mkDerivation

Rewritten almost everything to use overlays for handling args. The only issue I have right now is that I cannot call clearArgs inside an overlay. Maybe setting all those values to null? Doesn't sound right...

BTW, @TomaSajt, you should totally add transforms to stdlib

As @ShamrockLee mentioned previously it's very important to acknowledge is the following:

final in transformAttrs is the actual finalAttrs that's coming from inside mkDerivation
On the other hand, overridePythonAttrs is just a slap-on solution, so it only works in terms of the uppermost layer of attributes, so final in overridePythonAttrs means the fix-point of the args that will then be passed to transformAttrs.

Note:
to this day overridePythonAttrs doesn't know about whether the current package has been already overrideAttrs-ed, so it will gladly remove the effects of overrideAttrs, if done

Note:
to this day overridePythonAttrs doesn't know about whether the current package has been already overrideAttrs-ed, so it will gladly remove the effects of overrideAttrs, if done

So that you know, #267296 fixes the issue. Such issues are a good example of how custom overriders are hard to maintain and are not a good pattern.

You could just not use lib.extends, but a custom function I have been calling "transforms". It takes in a transformation instead of an overlay. If that transformation just does prevAttrs // at the beginning, it would act exactly like an overlay. However, since we now explicitly // the prevAttrs you could remove some unneeded names from prevAttrs before //-ing it.

here's the definition of transforms btw:

transforms =
  transformation: rattrs: 
    final: transformation final (rattrs final)

This function is similar to the lib.adaptMkDerivation in #234651 but without the functionArgs stuff.

Closing in favor of #271387