The package set is an attribute of the interpreter. The function to
build an environment (`buildEnv`/`withPackages`) is part of the
interpreter. The interpreter is passed to itself, and needs to be
updated when overridden.
For cross-compilation we splice the package set, and for that the
various `build/host` interpreters and sets need to be available. We
select these currently through `pkgs.${pythonAttr}`. The `pythonAttr`
attribute was not fixed for `pythonFull`.
https://github.com/NixOS/rfcs/pull/83https://github.com/NixOS/nixpkgs/pull/104201
We need a better solution for this because this is very brittle.
This was originally reverted because of an invalid patch.
This has been fixed and now we want this update again.
This reverts commit e1ed9b3b0851b95d3e82fb1085a121531c32a42a.
When overriding versions of build tools injected via hooks
`packageOverrides` was not taken into account and 2 incompatible
versions of the same package (`wheel` in this case) ended up in the
closure, causing the builds to fail.
As part of the splicing the build/host/target combinations of the interpreter
need to be passed around internally. The chosen names were not very clear,
implying they were package sets whereas actually there were derivations.
fixes c88f3adb1793cd3b007baff0292cf1fa8d0ab1e6, which resulted in
qt 5.15 being used in pythonPackages, despite 5.14 being
declared, and adapts qutebrowser accordingly.
'callPackage { pkgs = pkgs // { … }; }' does not work, because
it does not take into account the recursive evaluation of nixpkgs:
`pkgs/development/interpreters/python/default.nix` calls
`pkgs/top-level/python-packages.nix` with `callPackage`.
Thus, even if the former gets passed the updated `pkgs`,
the latter always gets passed `pkgs.pkgs`.
For the change in the qt5 version to apply consistently, 'pkgs.extend'
must be used.
qutebrowser only used the right qt5 version (5.15) because all
pythonPackages used it anyway.
