Should we remove support for PySide/PyQt4?

[mottosso]

Question for the community and users:

With the introduction of PySide6, should we remove support for PySide and/or PyQt4? If so, we could start to include members of Qt.py that exist in PySide2/PySide6, but not PySide/PyQt4, such as QGuiApplication.

Vote with a 👍 for "Yes" and 👎 for "No".

[dekekincaid]

Yes, major version up and drop qt4 support. If people really still want qt4 support they just use v1.x.

[MHendricks]

The dropping of classes like QTextCodec in 1.4 has already caused issues for us and I've had to resort to using the pip requirement of Qt.py==1.3.*.

[mottosso]

Looks like QTextCodec is not included in Qt 6 anyway, so even without PySide/PyQt4 this would still be missing.

• https://doc.qt.io/qt-6/qtextcodec.html

[matthewlow-dwa]

For potential guidance, the VFX Reference Platform recommends that: https://vfxplatform.com/

Providers of software libraries focused on VFX and animation content creation should aim to support their releases for the current calendar year and the three preceding years with compatible updates. Studios and end users should have no expectation of support for older libraries.

One way to interpret that recommendation is that Qt4 hasn't been supported since VFX Platform CY2015, well outside the current + 3 year window.

[dekekincaid]

Many libraries way outside the scope of vfx use Qt.py. The vfx platform has minimal to do with this project so it needs a longer tail than 3 years. That being said Centos/RHEL 7 is probably the last Linux distribution that still supports/ships with qt4. It is EOL at the end of June and it had a 10 year support period.

[mottosso]

Looks like this is the way to go. If anyone is up for submitting a PR with PySide and PyQt4 support dropped that would get the ball rolling. It'd consist of two primary steps.

1. Remove all PySide/PyQt4 code
2. Add all members that exist across both PySide2 and PySide6

To find out which members exist, one option is to:

1. Launch Maya 2024 and print(dir(QtCore))
2. Launch Maya 2025 and print(dir(QtCore))
3. Compare the two

Make a script of it and use set() to find the intersection, and presto. We've got Qt.py 2.0.0

[matthewlow-dwa]

While dropping PySide/PyQt4 is being worked out for an eventual 2.0.0 release, would it be worth it to make a 1.4.2 release to pick up the recent fixes for the PyQt5 regressions? https://github.com/mottosso/Qt.py/compare/1.4.1...master

[mottosso]

While dropping PySide/PyQt4 is being worked out for an eventual 2.0.0 release, would it be worth it to make a 1.4.2 release to pick up the recent fixes for the PyQt5 regressions? 1.4.1...master

Yes, definitely if there are fixes to be made that still holds up with PySide/PyQt4 then by all means submit a PR.

For the 2.0 without PySide/PyQt4, the table is set for any volunteer to begin with a PR.

[herronelou]

I know there was some conversation about this in https://github.com/mottosso/Qt.py/issues/367 already, but I'm starting to contemplate an update to PySide6 and have been doing some preliminary research to choose a path forward. I'm just this comment to think "aloud", as I haven't identified a single best approach yet.

I see the latest update that unlocks Qt 4, 5 and 6, still targeting the syntax of PySide2, and I can see us switching to that real soon. As time goes, though, we may want to target PySide6 syntax rather than PySide2 (not that many differences, but one day we will have Qt7, etc...), but that would require changes to existing code-bases, so keeping PySide2 syntax is probably best.

I could see a new major version that would drop Qt4, target 5 and 6, with the syntax of PySide2 being useful. As long as 7 isn't in the picture it doesn't get too awkward, and stays as a drop-in replacement in existing code, aside from whatever gets removed (thing that existed in 4 and 5 but not in 6).

In the other thread, there were also talks about making a separate package Qt6 or similar. I could see how Qt.py containing 2 modules at once could be useful, where existing code keeps using import Qt, while new code in the same repo could start to use import Qt6 and start using PySide6 syntax and features that did not exist in 4 but do exist in 5 and 6. It is extra work to support both in parallel though.

Ignoring the future and a possible Qt7, I think just having a new major of Qt.py keeping the same PySide2 syntax and targeting Qt 5 and 6 is the best compromise, as it doesn't require too much immediate code changes while bridging the 2 versions we now care about in VFX, which are 5 and 6.

[mottosso]

Regarding Qt 7+, bear in mind Qt.py is primarily about QtWidgets, which is frozen (semi-deprecated) since Qt 5. So it's reasonable to expect that as long as QtWidgets are included with Qt it will remain the same both in API and functionality; aside from syntax changes like these in Qt 6.

[MHendricks]

@mottosso regarding github actions and testing, would you be open to switching from docker and .sh files to using tox?

While I was working on PyQt6 support I noticed that the latest docker images are from 2018. The PySide6 testing seems to have dropped docker support as I'm guessing like me they didn't want to figure out how to setup the docker image. The latest docker images are for VFX platform 2018.

Now that PySide2, PyQt5, PySide6 and PyQt6 are all available on PyPi, I don't see the need for docker images. They were needed when you had to compile the Qt bindings yourself to run the tests. If we drop support for Qt4 and older versions of Qt5, it opens the door for just using tox.

I've already got an plan for how I would implement it but wanted to see if you had other plans? Unlike the PyQt6 change I can't justify working on this at work, so it would be a slow burn project in my free time but I already have a good idea of how to implement it.

I also have plans to convert from setup.py to pyproject.toml for pip packaging as I assume we will drop python 3.7 and below support at the same time.

[herronelou]

I just found out you have https://github.com/mottosso/Qt5.py should that become the bridge between 5 and 6 that dumps Qt4? Or is that too far off from the original intention of that shim?

[mottosso]

About this, do not let me be an obstacle; see #433

[MHendricks]

I'm working on prep for this change and have a few additional questions to guide the decisions.

1. Minimum version of python? We should definitely drop python 2 support. I'm thinking of matching the pythons available in the current ubuntu-latest on github actions. I think this is python 3.8(personally I use 3.9+). The last 3 releases of VFX Reference Platform only require python 3.10 and 3.11, but I'm not aware of any technical reasons we can't support older versions.
2. What binding is Qt.py a subset of? Currently its PySide2. I'm thinking we should we change it to PySide6. Current docs. This would affect if we expose Qt.QtSvg.QSvgWidget(PySide2) or Qt.QtSvgWidgets.QSvgWidget(PySide6). Similarly Qt.QtCore.QRegExp(Qt5) and Qt.QtCore.QRegularExpression(Qt5, Qt6). I think the main drawback of this would be it makes porting from Qt.py==1.4.* to Qt.py==2.0 a little harder to do, but that means your code is more ready for future updates to Qt.

For reference, I'm slowly working on improvements to the membership.py script in preparation for this. I wanted an easy reference of all the members for the supported bindings so it can now build markdown wiki pages like Membership between Qt5,Qt6 for reference. Also Qt4,Qt5,Qt6, Qt4,Qt5 for the older releases of Qt.py.

[dekekincaid]

Cy2022 is python 3.9 and QT5.15. I would love if we could still support back to this version since it is still active in most of our productions. Many larger studios including us are still in the middle of their Centos7 --> Rocky/Alma 9 transition so going to cy2023 is complicated by the OS move. We are compiling cy2023/cy2024-ish versions for Centos 7 simply because companies like SideFX is providing hybrid versions of their newer tools that are gcc 9.x and Qt5 & QT6 versions on Centos 7. Also Autodesk RV 2024 is in the same boat and has a cy2023 version. For Maya and Foundry tools though we are SOL and can't use them till we fully move over to Rocky 9 because of the glibc versions they are using.