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?
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 #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.