I’ve been trying to package an update (https://github.com/NixOS/nixpkgs/pull/247618). As part of it, I added a few dependencies for pyside6 in buildInputs. The whole PR works fine with python310, but it breaks with python311.
It seems that PYTHONPATH is missing build inputs when using python311, even on nixpkgs:master:
Update: The issue was that some qt6 modules pull in python3, but that dependency isn’t overridden when using python311 because qt6 isn’t a Python package. Fixed it in this commit.
Cool, nice catch and thanks for looking into it again - I was on the right track but couldn’t figure it out. Can you shortly explain how you get on the right track?
Is there a reason you preferred a patch over the substituteInPlace even it should be relative temporary as the code got changed for pillow > 10.0.0 which seems not backwards compatible? Should we suggest this change upstream for this reason as well?
I knew the issue affected pyside6 but not every Python package. So, I started removing pieces of the pyside6 derivation until I narrowed down the issue to the optional qt6 modules. Then, I checked for any python references in those modules, and saw that they are pulling in python3 but that qt6 is not part of pythonPackages. So, I checked how this is handled for other packages, and replicated that pattern for qt6.
As for the patch, I prefer the patch because it will cause a build failure when the upstream is updated, signalling that the patch can be removed. We’ll see what reviewers think.
I changed the version to latest develop release requiring release requiring at least python3.11. But despite different try’s (but this one was the most promising/comprehensible I always end up with:
nix log /nix/store/7zx1ydskf5597973acs81ijzay9fgz74-streamdeck-ui-3.1.0-develop.2.drv
warning: The interpretation of store paths arguments ending in `.drv` recently changed. If this command is now failing try again with '/nix/store/7zx1ydskf5597973acs81ijzay9fgz74-streamdeck-ui-3.1.0-develop.2.drv^*'
Sourcing python-remove-tests-dir-hook
Sourcing python-catch-conflicts-hook.sh
Sourcing python-remove-bin-bytecode-hook.sh
Sourcing pip-build-hook
Using pipBuildPhase
Using pipShellHook
Sourcing pip-install-hook
Using pipInstallPhase
Sourcing python-imports-check-hook.sh
Using pythonImportsCheckPhase
Sourcing python-namespaces-hook
Sourcing python-catch-conflicts-hook.sh
@nix { "action": "setPhase", "phase": "qtPreHook" }
qtPreHook
@nix { "action": "setPhase", "phase": "unpackPhase" }
unpacking sources
unpacking source archive /nix/store/hjic3ls7h9pwmlxxf8ncdismdgnb28zm-source
source root is source
setting SOURCE_DATE_EPOCH to timestamp 315619200 of file source/tests/test_stream_deck_monitor.py
@nix { "action": "setPhase", "phase": "patchPhase" }
patching sources
applying patch /nix/store/svlxvifkwni08pblaiaphiirxrw272zn-update-pillow.patch
patching file pyproject.toml
Hunk #1 succeeded at 14 with fuzz 2.
@nix { "action": "setPhase", "phase": "updateAutotoolsGnuConfigScriptsPhase" }
updateAutotoolsGnuConfigScriptsPhase
@nix { "action": "setPhase", "phase": "configurePhase" }
configuring
no configure script, doing nothing
@nix { "action": "setPhase", "phase": "buildPhase" }
building
Executing pipBuildPhase
Creating a wheel...
/nix/store/9hwaihb8rhlvq8s7xq11m204jp51h6xi-python3-3.11.4/bin/python3.11: No module named pip
does this make sense for you or would you just wait until it’s a stable release and have a look then?
Should we maybe do the change of qt-python before as it triggers far more rebuilds?
