We use pyqt4 internally, and are running into conflicts:
2014-10-01 12:44:15: RenderPluginException – Post job script “\S2\exchange\software\managed\pythonScripts\site-packages\scl\pipeline\insertRender.py”: post job script “\S2\exchange\software\managed\pythonScripts\site-packages\scl\pipeline\insertRender.py”: RuntimeError : the PyQt4.QtCore and PyQt5.QtCore modules both wrap the QObject class (FranticX.Scripting.PythonNetException)
Any ideas?
Guess upgrading to PyQt5 isn’t an option?
The python sandboxing coming in v8 would definitely help here, but for v7, I’m a bit stumped at the moment…
PyQt4 is used in most of our inhouse software, all of our standalone tools, 3dsmax, maya2012, nuke7 etc. while PySide is used in maya2014 and nuke8.
And all shared code has to work in all of these… For this purpose we have introduced a central scanlineQt library that imports the appropriate libs (pyside, pyqt5 or pyqt4), and tries to resolve incompatibilities by providing wrapper classes.
Right now it seems that the differences between qt4 and 5 are pretty big though (they split QtGui into QtWidgets and QtGui for example). What a headache 
Sandboxing would help somewhat, but any code run within the deadline environment would still have challenges. Dll hell on a whole new level.
We currently maintain 5 different complete python site packages folders based on python versions and compilers (2.5,2.6,2.7). For PyQt, we also have 5 different builds (some applications come with pyside, so those are not a worry), 6 builds of sip, etc.
Managed to sort some of these issues by creating a wrapper for pyqt.
Somewhat related, would be cool to get you guys on board with this:
Its a long shot, but at least a start!
Heh, looks like we’re already ahead with Qt. Definitely doesn’t hurt to take this into consideration though, so we’ll see what the list looks like for 2016.