In order to successfully test Qt.py against the different bindings of different versions, we use Travis-CI to run Docker containers based on pre-built CentOS-based images.
The Docker images follow the VFX Reference Platform specifications with some additionals, and are quite jam-packed.
Software built from source
- glibc1
- gcc1
- git2
- cmake3
- Qt44
- Qt5 + Autodesk-modifications1
- Qt5 Creator1, 5
- SIP4
- PyQt44
- PySide4
- PyQt51
- PySide21
1 Per specification from VFX Platform
2 Adds possibility to faster clone large repositories
3 cmake 3.x required to build PySide2
4 Required for Qt.py testing
5 Required for PySide2.QtUiTools
Software versions
We create new Docker containers when the VFX Reference Platform is updated; around the time of SIGGRAPH (usually July/August) each year.
We abide the software versions stipulated by the VFX Platform reference. But for other software required by Qt.py, we checkout specific commit SHAs or source archives rather than going for the always-latest version of software. This also helps to re-build Docker images later, if needed.
There are non-strict rules (guidelines) for choosing software versions to build:
- No commit SHA can be newer than the commit SHA from PySide2
- No binding's commit SHA can be older than their respective Qt commit SHA
Other noteworthy things:
- PySide cannot be built with anything newer than Python 3.4.
- SIP is used by both PyQt4 and PyQt5 and its version must therefore be chosen carefully.
- PySide2 does not have a maintained
__version__
string as of Qt.py v1.1.0.b3. - All Qt bindings and Qt itself are built using their respective 5.6.x branch.
Image tagging
A new image should be tagged like repo/qt.py:YYYY
. For CY2017, this translates into fredrikaverpil/qt.py:2017
.
If there happens to be an update inbetween VFX Platform specifications, a revision version number could be added: repo/qt.py:YYYY-update1
.
Enter the container
For debugging reasons, you can enter the container like this:
docker run --rm --interactive --tty --entrypoint=bash fredrikaverpil/qt.py:2017
You can then run python2.7
, python3.4
, python3.5
, python3.6
and so on (depending on which Python versions were built).
Dockerfile.vfxplatform2018
Software | Date | Details |
---|---|---|
PySide2 | 2017-08-24 | commit |
PySide | 2015-10-15 | commit |
SIP | 2016-07-25 | v4.18.1 |
PyQt5 | 2016-04-25 | v5.6 |
PyQt4 | 2015-08-01 | v4.11.4 |
Python 2.7 | 2015-12-05 | v2.7.11 |
Python 3.4 | 2017-08-09 | v3.4.7 |
Python 3.5 | 2017-08-08 | v3.5.4 |
Python 3.6 | 2017-07-17 | v3.6.2 |
Qt5 | 2016-06-16 | commit |
Adsk Qt5 qtbase |
2017-06-07 | commit |
Adsk Qt5 qtx11extras |
2017-02-24 | commit |
Qt5 Creator | 2017-08-09 | commit |
Qt4 | 2015-10-23 | commit |
cmake | 2017-07-18 | v3.9.0 |
glibc | 2012 (installed via yum) | 2.17 |
gcc | 2015 (installed via devtoolset-4) | [v5.3.1] |
Dockerfile.vfxplatform2017
Software | Date | Details |
---|---|---|
PySide2 | 2016-06-03 | commit |
PySide | 2015-10-15 | commit |
SIP | 2016-07-25 | v4.18.1 |
PyQt5 | 2016-04-25 | v5.6 |
PyQt4 | 2015-08-01 | v4.11.4 |
Python 2.7 | 2015-12-05 | v2.7.11 |
Python 3.4 | 2016-06-27 | v3.4.5 |
Python 3.5 | 2015-12-07 | v3.5.1 |
Qt5 | 2016-06-01 | commit |
Adsk Qt5 qtbase |
2016-06-28 | commit |
Adsk Qt5 qtx11extras |
2016-06-28 | commit |
Qt5 Creator | 2016-06-09 | commit |
Qt4 | 2015-10-23 | commit |
cmake | 2016-04-15 | v3.5.2 |
glibc | 2010 (pre-installed in CentOS 6) | 2.12 |
gcc | 2014-05-12 | v4.8.3 |