Question: Why pin PyQt to different versions for extra and for CI testing?

[penguinpee]

I just had a look at version 0.6.4, which doesn't build in Fedora since we have PyQt6 6.7.0 currently in our development branch. Not a big deal. But I noticed that commit 0ab6758 pins the version for extra pyqt6 to <6.7, whereas in .github/workflows/test_and_deploy.yml it is set to PyQt6<6.6 in the same commit.

Why? Shouldn't you be testing with the version that will be installed together with the package?

[tlambert03]

Hi @penguinpee, and thanks again for your help in packaging these things for fedora. Honestly, I'm really not sure what's going on with PyQt since yesterday's release of https://pypi.org/project/PyQt6-Qt6/ Environments were failing to load on CI, so I made some clean (local) environments with nothing by pyqt6 and qtpy, and they also had DLL issues on import, so it seemed the issue had nothing to do with superqt itself, but rather some new upstream binary incompatibility (which I assumed would be resolved upstream sooner or later).
Since superqt tries as hard as possible not to restrict the version and/or backend of Qt that end-users use, I didn't go so far as to hard-pin anything here, leaving it to end-users.

I feel relatively confident that 0.6.4 didn't contain anything that would suddenly make superqt incompatible, so is it possible that your build is now failing simply because of that upstream problem (which might have gone unnoticed in your builds had v0.6.4 not triggered your tests?)

[tlambert03]

i would be curious to see your build failures too. do you have public logs for them?

[tlambert03]

it's possible, though I haven't looked into this or verified it yet, that PyQt6-Qt6 started doing a similar lazy-loading thing to what PySide6 was doing that is causing problems with qtpy: https://github.com/spyder-ide/qtpy/issues/480

[penguinpee]

It was not building simply because No match for argument: python3dist(pyqt6) < 6.7~~. I seemed to remember that pqt6 was not pinned in any way previously, so I went looking and I noticed the difference between pyproject.toml and test_and_deploy.yml in the commit. That sparked my curiosity.

With the upper bound removed, things build fine downstream. Well, I haven't been able to get the tests working. But that has lower priority on my list, seeing that upstream tests as well.

I believe other maintainers are still busy ironing out issues in the Qt6 stack, though. We only have it available fully in rawhide (development).

[penguinpee]

it's possible, though I haven't looked into this or verified it yet, that PyQt6-Qt6 started doing a similar lazy-loading thing to what PySide6 was doing that is causing problems with qtpy: spyder-ide/qtpy#480

Thanks for pointing that out by the way. I'm planning to update Spyder in Fedora, both 5.x and 6.x releases, soon. This might become relevant. Spyder is also what brought superqt on my path. :jigsaw:

[tlambert03]

That sparked my curiosity.

Yeah, I guess the answer to your question is "because I assumed it was a temporary upstream Qt issue, and because superqt doesn't actually demand the installation of pyqt (making it hard to pin)"

[penguinpee]

We don't make PyQt or PySide a runtime requirement either. It's being installed at build time purely for the tests. Whenever possible we want to run tests downstream as well. It's useful since versions in our repository don't always match what upstream has pinned. It gives an idea at least if something is on fire.

[tlambert03]

yeah, understood. this is indeed a tricky case i guess. In general, i would say it is absolutely the intention of superqt to be compatible with the latest version of pyqt5 pyside2 pyqt6 and pyside6 (all via qtpy). but that assumes that those packages are themselves installable and importable. I will unpin the test requirements once the upstream issues resolve themselves