Python needs splicing

[Ericson2314]

Describe the bug
Non-buildInputs that are python packages shouldn't be provided by the same package set in cross builds.

(Grep __splicedPackages so see the nasty stuff the Haskell and xorg package sets do today, that's what we need to cargo cult.)

I'm happy to help fix this, but it would be nice to do in conjunction with the python maintainers rather than pure async.

To Reproduce
On staging today fad48e3:

 $ nix-diff /nix/store/ampk9xikalzrlmcnn69jk056xnj1bfma-python2.7-PyStemmer-2.0.1.drv /nix/store/78l2xl541qn32qsv2as3zg88s6dh9qr6-python2.7-PyStemmer-2.0.1.drv
- /nix/store/ampk9xikalzrlmcnn69jk056xnj1bfma-python2.7-PyStemmer-2.0.1.drv:{out}
+ /nix/store/78l2xl541qn32qsv2as3zg88s6dh9qr6-python2.7-PyStemmer-2.0.1.drv:{out}
• The input named `python2.7-Cython-0.29.21` differs
  - /nix/store/kx6nqrm0k5vsri107pshj0ar5arawzih-python2.7-Cython-0.29.21.drv:{out}
  + /nix/store/xr0g9x2m0mhy39rhsi7vb4nzjswxzbcp-python2.7-Cython-0.29.21.drv:{out}
  • The set of input names do not match:
      - aarch64-unknown-linux-gnu-gdb-10.1
      + gdb-10.1
  • The environments do not match:
      buildInputs=''
          /nix/store/nwk8rivbjixsi9f9aghdx3940ga5px0w-glibc-locales-2.32 /nix/store/pxq11mmxrlqqmzjsv2cx8r9kqq75f8j73ap194mbw5-aarch6p2jb4-unknoy6rwn-gxqfwlinu6x-gnu-gdb-10.1
      ''
• Skipping environment comparison

Expected behavior
those two derivations are the same

Additional context

• GDB in particular maybe could be more multi-target, but nevermind that for now.
• Cython I suppose should be able to cross compile, so it makes sense that GDB might really need to be used with non-native binaries.

Notify maintainers
CC @FRidh

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: HUGE, but cross-only
# a list of nixos modules affected by the problem
module: probably big too

[FRidh]

Yes, we definitely need this. I have however no idea how to do this.

See also #49526 and #53320.

[cdepillabout]

@Ericson2314

Grep __splicedPackages so see the nasty stuff the Haskell and xorg package sets do today, that's what we need to cargo cult.

I think this is the code you're talking about in the Haskell stuff:

nixpkgs/pkgs/development/haskell-modules/make-package-set.nix

Lines 99 to 114 in 9a38c3a

	mkScope = scope: let
	ps = pkgs.__splicedPackages;
	scopeSpliced = pkgs.splicePackages {
	pkgsBuildBuild = scope.buildHaskellPackages.buildHaskellPackages;
	pkgsBuildHost = scope.buildHaskellPackages;
	pkgsBuildTarget = {};
	pkgsHostHost = {};
	pkgsHostTarget = scope;
	pkgsTargetTarget = {};
	} // {
	# Don't splice these
	inherit (scope) ghc buildHaskellPackages;
	};
	in ps // ps.xorg // ps.gnome2 // { inherit stdenv; } // scopeSpliced;
	defaultScope = mkScope self;
	callPackage = drv: args: callPackageWithScope defaultScope drv args;

Is there some documentation around this? I feel like I am missing the larger picture around this, including what sort of derivations should actually make use of this functionality, how it is implemented under the hood, and what the relationship is to things like pkgsBuildBuild, pkgsHostTarget, nativeBuildInputs, etc. I'd be happy with even just a blog post or a video from a presentation about it!

The only documentation I've found is a comment in splice.nix, but it doesn't really give a lot to go on:

nixpkgs/pkgs/top-level/splice.nix

Lines 1 to 23 in 9a38c3a

	# The `splicedPackages' package set, and its use by `callPackage`
	#
	# The `buildPackages` pkg set is a new concept, and the vast majority package
	# expression (the other *.nix files) are not designed with it in mind. This
	# presents us with a problem with how to get the right version (build-time vs
	# run-time) of a package to a consumer that isn't used to thinking so cleverly.
	#
	# The solution is to splice the package sets together as we do below, so every
	# `callPackage`d expression in fact gets both versions. Each# derivation (and
	# each derivation's outputs) consists of the run-time version, augmented with a
	# `nativeDrv` field for the build-time version, and `crossDrv` field for the
	# run-time version.
	#
	# We could have used any names we want for the disambiguated versions, but
	# `crossDrv` and `nativeDrv` were somewhat similarly used for the old
	# cross-compiling infrastructure. The names are mostly invisible as
	# `mkDerivation` knows how to pull out the right ones for `buildDepends` and
	# friends, but a few packages use them directly, so it seemed efficient (to
	# @Ericson2314) to reuse those names, at least initially, to minimize breakage.
	#
	# For performance reasons, rather than uniformally splice in all cases, we only
	# do so when `pkgs` and `buildPackages` are distinct. The `actuallySplice`
	# parameter there the boolean value of that equality check.