python3: propagate overrides of spliced pythons

[doronbehar]

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.

[lheckemann]

If I understand correctly, this would still have the surprising override-dropping behaviour if inputs to the python package are overridden, e.g. python.override { sqlite = sqlite-interactive; }?

[doronbehar]

If I understand correctly, this would still have the surprising override-dropping behaviour if inputs to the python package are overridden, e.g. python.override { sqlite = sqlite-interactive; }?

That behavior was present before 6421482 , due to the !lib.isDerivation condition used in the filter. TBH I'm not sure why that filter function was breaking the splicing for pkgsCross.armv7l-hf-multiplatform.buildPackages.python3Packages.setuptools-rust. After opening the current PR, I noticed the Lua ecosystem also uses the same filter and pretty much the same code:

nixpkgs/pkgs/development/interpreters/lua-5/interpreter.nix

Lines 191 to 202 in f3f83f3

	# copied from python
	passthru =
	let
	# When we override the interpreter we also need to override the spliced versions of the interpreter
	inputs' = lib.filterAttrs (n: v: !lib.isDerivation v && n != "passthruFun") inputs;
	override =
	attr:
	let
	lua = attr.override (inputs' // { self = lua; });
	in
	lua;
	in

I'm involved in cross compilation of lua packages too, and I haven't noticed equivalent issues. Maybe that's due to the @inputs in lua-5/interpreter.nix v.s cpython/default.nix.

Do you think the correct thing to do now would be to investigate why this lib.filter won't work for Python? Or maybe add a NOTE comment?

[lheckemann]

Given that this PR doesn't introduce any new breakage, and at least partially fixes the existing breakage, I think it's good.

Maybe opening a new issue would be better than a note, but I'm also not sure if anyone really has the problem I'm describing (I do struggle to think of a real use case for overriding python inputs where an overlay replacing the package for all of nixpkgs wouldn't be the more sensible approach).

[doronbehar]

@lheckemann I just realized that packageOverrides - an important @inputs argument should also be propagated to all of these Pythons, so I added it, along with a comment striving to thoroughly explain the situation. If you could give it one more round of review it'd be great.

[lheckemann]

Seems sensible :)

[lheckemann]

This does fix the specific problem I was having though, thanks for looking into it!