Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
penguinpee opened this issue Apr 26, 2024 · 8 comments
Closed
Labels
bug Something isn't working

Comments

@penguinpee
Copy link

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?

@penguinpee penguinpee added the bug Something isn't working label Apr 26, 2024
@tlambert03
Copy link
Member

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
Copy link
Member

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

@tlambert03
Copy link
Member

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

@penguinpee
Copy link
Author

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
Copy link
Author

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. 🧩

@tlambert03
Copy link
Member

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
Copy link
Author

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
Copy link
Member

tlambert03 commented Apr 26, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Development

No branches or pull requests

2 participants