Thoughts about CY2019 and Qt.py

I just added testing with CY2018 update 1 as a PR, although I don’t think we need to merge it in its current state as it doesn’t provide any extra value as of now. I merely completed it as I wanted to learn how to solve some issues entailed with setting that new container up.

However, when completing that PR, some ideas sprung up, which I’d like to raise.

sip

For the upcoming CY2019, we want to up the PyQt5 version substantially, and make it on par with PySide2. This would mean using Qt 5.12, PySide2-5.12, PyQt5-5.12. There is one major issue with this, and that is that there’s not a sip version compatible with such a recent PyQt5 version and PyQt4. To my knowledge only one sip-version can be installed in an environment and both PyQt bindings will use that sip.

And the way we are currently running tests is that in each Python installation (2.7, 3.4, 3.5, 3.6), we are also installing sip, PyQt4, PyQt5, PySide (shiboken) and PySide2 (shiboken2). This has worked so far, as we have been using a sip/PyQt4/PyQt5 compatible combo cocktail. In retrospect, I should’ve seen this coming as there’s no 🎲 that PyQt4 will be updated to support the most recent sip.

I will get back to the topic of sip further down below…

There are now official wheels, so why build for vfxplatform?

In the very early days of Qt.py, we just installed Python wheels and didn’t muck around with building stuff from scratch. This, however, resulted in loss of control when e.g. Ubuntu PPAs were no longer maintained. CI/testing started breaking and in order to fix this, we decided to build software from individual git commits and specific software versions. By storing such builds as docker containers in dockerhub, we could be pretty sure that these configurations would last even if software grew old and their respective maintainers would abandon old versions.

So, beginning with CY2017, we’ve been building Qt from scratch so that we can control exactly which versions of bindings we are testing against. At this point we also decided why not build according to the vfxplatform spec. But in my mind, following that spec was secondary to building everything from source for increased control.

Building software from source seems like an obsolete scenario to me now (and an increasingly painstakingly daunting task), as PySide2 is just about to be stable and have a maintained version string (PySide2.__version__). Sure, it may not be built with the exact spec stipulated by the vfxplatform, and it won’t contain any Autodesk-specific modifications. But do we really have to care about this? We aren’t really testing Qt.py for Maya in particular and I think it’s time to let loose and go DCC agnostic and simply make sure that Qt.py play nice with the vanilla bindings. We can always fix stuff which may arise due to the fact that a DCC app is misbehaving and add appropriate tests with mock data for such cases.

We are starting to tread out of the muddy waters of being the pioneers developing with PySide2, which feels great. I would like to embrace this fully and when moving forward, I wish we could just pip install wheels rather than build stuff from scratch like we’ve done with past containers.

My proposal moving forward

• Drop testing for PyQt4 and PySide in future testing (but keep the ones we have). We already have containers with these bindings and there are not much to gain from maintaining newer versions of these as development for PySide has stopped and drastically slowed down for PyQt4. It’s just a pain to build these moving forward.
• Keep using the current nosetests suite (it works, why change it?)
• Start pip installing wheels (PyQt5 and PySide2) rather than building from source and rely on past docker containers to complete tests for the older bindings. Wheels would be stored somewhere so that they can be re-downloaded later.
• Possibly keep the current docker container creation workflow which would allow for building software if this need would arise again in the future.

Issues resulting from the above proposed changes:

• Today, we generate a dictionary of common binding members by running build_membership.sh. The way this works is that a members .json is dumped for each binding. A new .json is generated, containing only the members found in all previously generated json files. In the past, we’ve used the same docker container to produce these. With the changes above, we’ll have to make a specific container dump the “legacy” bindings .json files and then use the latest container to dump the PySide2/PyQt5 .json files.
• entrypoint.sh can be modified to that it will not run tests for the “legacy” bindings unless a container running equipped with said bindings is executing.

---

@mottosso @MHendricks @Ahuge @dgovil and others - what do you think? PS. Anyone of you going to SIGGRAPH this year, would ❤️ to catch a 🍺 or 🍻 !

[cmaureir]

I will try to start this discussion internally to see if we will be able to make a decision soon, so you can be aware of it.

[mottosso]

If you major version bump this and don’t make it a separate package/module that we have to import from, you allow us to keep our code base in it’s current form and drop Qt4 when we want and not have to do another major refactor.

That is a good point. If there’s one thing to look out for with that it would be that although you will at some point be able to drop Qt 4, you would not be able to use any features unique to Qt 5 until that has happened.

Conversely, with a separate Qt5.py, you could employ those features projects right away and in parallel to your existing projects.

But there will come a time when Qt 6 is out and we’ll need a 5-6 wrapper. When that happens, it’s no longer clear what Qt.py means, and I’m not entirely convinced a relatively hidden aspect like version is a strong enough deliminator for someone reading code and know without a doubt that it’s using Qt 4, 5 or 6.

Perhaps Qt.py should be Qt4to5.py, followed by Qt5to6.py? Not as catchy, but more explicit. Then at some point, if we’re lucky, we’d get Q T 9 to 5, what a way to make a livin'