From fc74ad444af06291f367a6d50dd70f010392cd33 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Wed, 3 Mar 2021 16:38:16 +0000 Subject: [PATCH] buildPythonPackage: Fix after #112276 Fix #114952 Before it was using the wrong `makeWrapper`, the one that expected to run on the target platform and produce packages for the "super-target". The "super target" (sliding off the end of the platforms list) is defined to be the same as the target, to cap it with a loop so there is no sliding off. However, `targetPackages.targetPackages` is *not* similarly defined. Per the bottom of `pkgs/stdenv/booter.nix` it is an almost-empty package set that just exists as a hack to help some things with exotic `depsTargetTarget`. In particular, that rump "super `targetPackages`" does not contain a `runtimeShell`, and that's the source of our eval-time error. --- pkgs/top-level/python-packages.nix | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/pkgs/top-level/python-packages.nix b/pkgs/top-level/python-packages.nix index 4673bb8d200e..7eb17fe1d782 100644 --- a/pkgs/top-level/python-packages.nix +++ b/pkgs/top-level/python-packages.nix @@ -126,7 +126,13 @@ in { # helpers - wrapPython = callPackage ../development/interpreters/python/wrap-python.nix {inherit python; inherit (pkgs) makeSetupHook makeWrapper; }; + # We use build packages because we are making a setup hook to be used as a + # native build input. The script itself references both the build-time + # (build) and run-time (host) python from the explicitly passed in `python` + # attribute, so the `buildPackages` doesn't effect that. + wrapPython = pkgs.buildPackages.callPackage ../development/interpreters/python/wrap-python.nix { + inherit python; + }; # Dont take pythonPackages from "global" pkgs scope to avoid mixing python versions pythonPackages = self;