lib.customisation: add getFinalPassthruWith for unified missing finalAttrs.passthru.<attr> handling

[ShamrockLee]

Following the increased adoption of fixed-point attributes (finalAttrs: { }) and <pkg>.overrideAttrs-based overriding, some arguments are referenced and overridden under finalAttrs.passthru, accidental overriting/emptying of the passthru attributes could result in surprising errors/behavioural changes that is hard to identify and debug.

This PR provides two new Nixpkgs Library functions, getFinalPassthruWith and getFinalPassthruMissingMessage, which gets the attribute from finalAttrs.passthru and fall back to specified behaviours with informative error/warning message including the possible position of the last passthru overriding.

See the followings for context:

• buildGoModule: be nicer when overrideAttrs clears passthru #339042
• buildGoModule: warn for passthru.overrideModAttrs lost after overriding #434546

Aside from buildGoModule, recent buildPythonPackage overriding improvement will also benefit from this library function.

• buildPythonPackage: Enable direct attribute overriding via overrideAttrs (the non-staging ones) #376372

Questions:

• Should these functions be defined under lib.meta instead of lib.customisation?
• Should getFinalPassthruWith has a signature of { handler, prefix, finalAttrs } -> attrName -> Any instead of { handler, prefix } -> finalAttrs -> attrName -> Any?

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[ShamrockLee]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 446760
Commit: d2d22c30d551018376fc9fff0479694416eb104b

---

x86_64-linux

⏩ 2 packages blacklisted:

• nixos-install-tools
• tests.nixos-functions.nixos-test

✅ 1 package built:

• nixpkgs-manual

[ShamrockLee]

I added some test cases.

[philiptaron]

Due to the SC election, I haven't had a chance to look at this.

[ShamrockLee]

Due to the SC election, I haven't had a chance to look at this.

No hurry.

This kind of interface design takes time to gather broader inputs and consensus. We might also update the fixed-point arguments documentation afterward. In addition, backporting this function and substituting existing warning/throwing causes no rebuilds.

[wolfgangwalther]

I have not looked at this our thought about this in-depth, but my gut tells me this is overly specific to be put in lib.

[ShamrockLee]

I have not looked at this our thought about this in-depth, but my gut tells me this is overly specific to be put in lib.

This is a very valid point. this function is tightly coupled to the stdenv.mkDerivation interface, and downstream projects using the Nixpkgs library does not necesarily use stdenv.mkDerivation. (It's different from lib.extendMkDerivation; the latter is essentially lib.extends with argument exclusion.)

Should we move it under stdenv?

Still, considering the existence of lib.meta and lib.meta.setPrio, how independent of Nixpkgs library from pkgs do we expect?

[philiptaron]

Should we move it under stdenv?

The alternative, in my mind, is to put it next to make-derivation.nix, maybe in pkgs/stdenv/generic/passthru.nix and have that specific file be imported by pkgs/test/stdenv/default.nix and tested that way. Much of what's in make-derivation.nix could be extracted and unit tested in this way, I note.