Replace overridePythonAttrs with overrideArgs, add for Rust and Go as well

[alyssais]

Motivation for this change

This allows, eg, specifying a custom src to use a different version of a package, like overrideAttrs does for normal packages, or overridePythonAttrs for Python packages.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• 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 nox --run "nox-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)
• Fits CONTRIBUTING.md.

---

[matthewbauer]

Maybe we should normalize this name to something like overrideArgs or something... This kind of thing could become common across different packages.

[alyssais]

I think that would be a good idea, especially since I've already needed overrideGoAttrs (#47425). overrideArgs isn't a very clear name – I'd expect that to do what override does now, but maybe there isn't a better one. I'll have a go at implementing it anyway, converting what already exists, and we could change the name if we think of a better one.

[alyssais]

I’ve renamed overridePythonAttrs to overrideArgs, done the same for overrideRustAttrs, and added one for Go to replace #47425.

[FRidh]

I am against renaming the functions in this PR. overridePythonAttrs is used a lot outside of Nixpkgs already and I don't want to do any such ad-hoc standardization without going through an RFC where we identify and decide on parts to standardize.

[alyssais]

Going through an RFC makes sense I suppose

[alyssais]

@matthewbauer would you be willing to co-author an RFC?

[FRidh]

• overrideDerivation is used to override the call to derivation
• overrideAttrs is used to override the call to stdenv.mkDerivation
• override is used to override the last function call. Often this will be the callPackage call.
• overridePythonAttrs is used to override the call to buildPython*.

@alyssais what you are interested in, overrideArgs, is having a standard call to build*Package functions.

The buildPython* function calls stdenv.mkDerivation with a modified set of arguments that were passed to itself. In the case of Python packages there is no valid reason for using overrideAttrs anymore. Seeing that, and assuming it's the same for other build*Package functions, we could say these build*Package functions should simply use overrideAttrs for overriding the call to them.

[alyssais]

The `buildPython*` function calls `stdenv.mkDerivation` with a modified set of arguments that were passed to itself. In the case of Python packages there is no valid reason for using `overrideAttrs` anymore. Seeing that, and assuming it's the same for other `build*Package` functions, we could say these `build*Package` functions should simply use `overrideAttrs` for overriding the call to them.

Interesting. Indeed, I'm having trouble thinking of a situation in which I'd want to call overrideAttrs on a Python/Go/Rust package -- if the build*Package function is sufficiently customisable, it should be possible to change everything I could possibly want to change through that. My one concern with such an approach is that it could be surprising to have overrideAttrs do different things depending on how mkDerivation was ultimately invoked, but I think it could be argued that the current situation, where using overrideAttrs will just break things and there's no supported way to eg add patches at all is even more surprising.

[FRidh]

In the case of buildPython*, everything that's given is passed along to stdenv.mkDerivation, it's just that along the way it modifies some attributes. At the time when I added this it was hard to say whether reusing overrideAttrs for this would be a problem, but in retrospect I think it could have been fine.

I agree with you that it could be confusing if a build*Package.overrideAttrs behaves somewhat differently from stdenv.mkDerivation.overrideAttrs. So that would be a good argument against reusing overrideAttrs.

[CMCDragonkai]

Why stop at python, go and rust. I want this in Haskell too and everything else.

[FRidh]

#82772 maps overrideAttrs to overridePythonAttrs. Maybe this can be done with the other builders as well?

[FRidh]

RFC proposal https://github.com/NixOS/rfcs/compare/master...FRidh:overrideattrs?expand=1
Shall we go through with that?

[danbst]

@FRidh would it be hard to actually define full builder hierarchy for this RFC? Of top of my head, there are:

* derivation { }
** stdenv.mkDerivation {}
*** runCommand* {} and other trivial builders (writeFile, writeScript, writeScriptBin)
**** buildEnv
***** python.withPackages {}
*** python.pkgs.buildPythonPackage {}
*** python.pkgs.buildPythonApplication {}
*** mkDerivation {} # <-- Qt (!) TODO rename
*** androidenv.buildApp {}

there are many more, but at least it would good to know that python.withPackages is a different branch than buildPythonApplication, and it can also be overriden.

Maybe this hierarchy can be crowdsourced as part of RFC

[FRidh]

@danbst I've opened a PR now, please post on NixOS/rfcs#67

[stale]

I marked this as stale due to inactivity. → More info

[nyabinary]

This should be closed, right? Since it uh pretty stale