Pyside6 migration?

I know we’re a little early for VFX Reference Platform 2024, but I’m curious if anybody has looked in to what changes are needed to support pyside6 yet?

One of my main motivations here is being able to use Pyblish-QML with pyside again. That’s blocked by this issue: Pyside2 5.15.1/5.15.2: constant property commentEnabled throws TypeError (WRITE method or NOTIFY signal) · Issue #369 · pyblish/pyblish-qml · GitHub The bug has been fixed upstream, but getting another release of pyside2 that includes the fix doesn’t seem very promising at this point. Therefore, moving to pyside6, where released versions have included the fix for a long time, seems like the most sensible option.

Hey, sorry for the late reply on this one.

I wouldn’t worry too much about Pyblish QML supporting Qt 6, unless the development of Pyblish QML needs any of those features. As far as Maya/Blender/Unreal/etc is concerned, Pyblish QML is still running in its own interpreter, with its own PySide2/PyQt5 so DCCs should be able to keep up with VFX platform and what not without bothering with implementation details of Pyblish QML?

That said, I’ve pushed a minor update to it to work around the issue you listed.

Let me know if I’m missing some usecase you’ve got in mind, other than working around this one issue. The better option really would be to implement the fix on the Pyblish QML side rather than wait for the world to change.

Speaking of which, the project could really use a maintainer, someone who uses it on a daily basis. Sadly I do not personally use it anymore and haven’t for almost a decade now. :sob: But many still do, and it is still relevant to current and future production pipelines. If you or anyone is interested, ping me here or on any of the GitHub projects.

VFX reference platform and DCCs aside, I suppose the bigger issue is that Qt 5.15 has been out of support for non-subscribers for almost a year now and will reach end of support for subscribers in May 2025. Keeping an old version of Qt around for Pyblish is certainly feasible in the short term, but without active maintainers it’ll just get more and more difficult to use the project.

What kind of support are you looking to benefit from with Qt 6?

We’re using the GPL licenced version of Qt, there’s no support either way. And besides, even Maya 2019 is still in production for at least a few more years, with Python 2.7 and all that that entails.

The idea is not to keep Qt around for Pyblish QML, but to consider Pyblish QML a completely sandboxed piece of software, that happens to internally use a version of Qt under the hood. Which version that is is an implementation detail. With that script I put together above, it’ll create such a distribution that will continue running without issue for as long as Windows maintains backwards compatibility with .exe files.

All of this said, it would be great to move Pyblish QML to PySide6 for sake of development. High DPI support is one of things I notice as missing on my machine, and wasn’t a thing back when Pyblish QML was first written. The door is open for someone interested in taking it in that direction.

I haven’t tried this script, but it looks like it is installing PySide 5.15.2. What got me started looking at this was the Pyblish bug I linked in my original post. As described in that report, it is actually a upstream bug that only existed in 5.15.1 & 5.15.2 and then got fixed. However, AFAIK that fix never made it in to a released version of PySide 5 so it seemed like we were stuck with either downgrading to an even older version of Qt 5 or starting to migrate to 6.

It is, but you can control which version it picks, I picked the one Maya 2022 used.

./build_distribution.ps1 pythonVersion=3.10.11 qtVersion=5.15.0


That said, I’ve also already updated Pyblish QML to not trigger this bug anymore, so even 5.15.2 will work from now on.

Ah cool, thanks. When I ran across this last winter I had a Conda environment with Pyblish-lite, wanted to try something with Pyblish-qml, hit this issue and posted here, but didn’t investigate further because it wasn’t a big enough need at the time.