Building with Python 3, Qt 5 on Ubuntu 18.04

[kkremitzki]

it should have just been built against the system Qt.

Hmm, I'm not sure if that's going to work, at least with the PySide2 deb that's currently available. Ubuntu 18.04 ships with Qt 5.9, but I think the PySide2 deb is built with Qt5.11.

It doesn't work out of the box but only requires a very small patch to work with Qt 5.9. I'm using a tweaked version of the source package which is built to make the package you linked at https://tracker.debian.org/pkg/pyside2. (The tweaked source package I'm using is at https://salsa.debian.org/qt-kde-team/qt/pyside2.)

This ends up being OK because PySide 2 was *almost* working for 5.9, but ended up being released for 5.11. However, the Qt version in Ubuntu 16.04 is indeed too old. Trying to build my source package against it resulted in enough errors that I decided to switch to another task and come back to it later.

[wmayer]

The daily PPA currently has PySide 2 packages uploaded for 18.04 only; I tried uploading my Pivy package as well, which depends on PySide 2, but for some reason it wasn't able to find the packages and failed to build.

Does it have a build dependency to PySide2? IIRC, the old Pivy didn't have a build dependency to a Python binding for Qt (at that time only PyQt was available) but tried to load it at runtime. With PySide(2) there is also a way not to wrap/unwrap Qt classes via C++ but via Python so to avoid the build dependency.

* Building with Qt 4 and Python 3 is tricky, because some of the PySide (not PySide2) tools/libraries want to pull in Python 2 libraries. The packaging dependencies are such that you can't install everything we need from PySide only for Python 3...

I would avoid this combination since Qt4 will disappear soon from future releases of all major Linux distributions and Py2 will follow soon. It's not worth to put any effort to make this working.

* Ubuntu 18.04 is distributed with Qt5.9.5, but most of the PySide2 packaging at this stage is for Qt5.11

Is it? I know that with the release of Qt5.11 it was officially announced that PySide2 will be part of Qt. But I recently build PySide2 on Windows against Qt < 5.11 and can't remember of any build failures. So far, the only problem is that the Python modules contain stupid suffixes in the file names and that the debug versions don't have the required "_d" suffix. Also, the PySide2 source code is not part of the Qt source tarball but you have to download it separately.

[kkremitzki]

The daily PPA currently has PySide 2 packages uploaded for 18.04 only; I tried uploading my Pivy package as well, which depends on PySide 2, but for some reason it wasn't able to find the packages and failed to build.

Does it have a build dependency to PySide2? IIRC, the old Pivy didn't have a build dependency to a Python binding for Qt (at that time only PyQt was available) but tried to load it at runtime. With PySide(2) there is also a way not to wrap/unwrap Qt classes via C++ but via Python so to avoid the build dependency.

It does not technically build-depend on PySide 2, but its tests do use them. Since I had the packages included in debian/control, when they weren't found the build failed although it could have technically proceeded (although the packages themselves wouldn't have worked since they do have the runtime dependency you mentioned.)

Anyway, Ian's description of the problem was enough for me to figure it out; I rebuilt the PySide 2 package and Pivy (at least on i386) has built successfully. So, once it's done on amd64 as well, I should be able to take the packaging for freecad-daily, do some sort of s/daily/python3/, update the dependencies in debian/control, add some flags in debian/rules, and finally have a Qt 5/Python 3 package uploaded.

[NormandC]

Just wanted to say that my Ubuntu Update Manager pushed the python-pivy-0.6.4 update today, along with shiboken2 and pyside2 packages.

Was a little worried it would break the freecad and freecad-daily packages but everything seems to work as expected for now.

[sgrogan]

Was a little worried it would break the freecad and freecad-daily packages but everything seems to work as expected for now.

Should I start splitting the packaging for the FreeCAD-daily PPA?
14.04 is going to be what it is.
16.04 maybe we can get netgen working.
18.04 + we go for PY3/QT5.

[ian.rees]

* Ubuntu 18.04 is distributed with Qt5.9.5, but most of the PySide2 packaging at this stage is for Qt5.11

Is it? I know that with the release of Qt5.11 it was officially announced that PySide2 will be part of Qt. But I recently build PySide2 on Windows against Qt < 5.11 and can't remember of any build failures. So far, the only problem is that the Python modules contain stupid suffixes in the file names and that the debug versions don't have the required "_d" suffix. Also, the PySide2 source code is not part of the Qt source tarball but you have to download it separately.

Yeah, both the pip and the Debian packages I've seen are for Qt5.11. Homebrew is also at Qt5.11.

[NormandC]

Should I start splitting the packaging for the FreeCAD-daily PPA?
14.04 is going to be what it is.
16.04 maybe we can get netgen working.
18.04 + we go for PY3/QT5.

To be honest, with kkremitzki's great work, I'm more and more out of touch with packaging. Good luck with netgen! As for Py3/Qt5 for 18.04, why not. This is a devel build after all, it would bring in a lot more testers. As long as it does not conflict with the Py2/Qt4 0.17 stable package, users would have a fallback.

[triplus]

Likely Conda isn't easier per se. Both Conda and Ubuntu/Debian/PPA efforts require packaging effort.

One thing that is simpler, is dealing with different versions of the same package. There is always only one qt and only one python version in one environment (conda)
Dealing with different versions of the same package has high potential to mess up a system. I know ubuntu and Debian try to solve this, but still it's only a workaround. In the end you want a system to be as consistent as possible, and therefor different versions of the same packe should be avoided. This is true for any dependency (boost, python, qt,...)

Hopefully there are some py3-only distros available soon...

Not sure as i was able to compile Py2/Qt4, Py3/Qt4, Py2/Qt5 and Py3/Qt5 in the past on Ubuntu 16.04. By defining a few CMake build options. The reason on why it is a bit easier for Py2 is because that is the default interpreter on Ubuntu. And you don't' have to define any paths and things like that. To find and use Py2 interpreter.

Well, could you please describe how to do it then?

I can' give the exact instructions for Ubuntu 18.04 as i haven't tested that yet. There was a PySide2 PPA (daily) in the past i used. Not related to PySide2 added by @kkremitzki on FreeCAD PPA. And as for Pivy i installed the package @looo provided on his personal PPA. That did the job for me.

For Py3 builds procedure like this is needed (paths change slightly depending on the Python version available on specific Ubuntu version):

https://forum.freecadweb.org/viewtopic. ... 10#p238646

As for the Qt5. There is basically a CMake option to enable Qt5 build. When it comes to Qt5 builds this was the thread that enabled me to create the first one:

https://forum.freecadweb.org/viewtopic. ... 50#p208325

[kkremitzki]

So, now that python3-pivy and python3-pyside2.* packages are available in the PPA, once you've gotten all the dependencies installed, a Qt 5/Python 3 build seems to be as simple for me as:

Code: Select all

cmake ../repo -DBUILD_QT5=ON -DPYTHON_EXECUTABLE=/usr/bin/python3 && make -j$(nproc)

[triplus]

Good to hear that. If things like PYTHON_SUFFIX and PYTHON_BASENAME don't have to be set explicitly anymore. If that was omitted in the past Python2/3 library mismatch did happen. Possible compile issues and things like FreeCAD crashing on imports was the result.

P.S. Likely related to on how things on the PySide2 PPA were packed compared to PySide2 from FreeCAD PPA. Some fixes likely got upstreamed too as PySide2 PPA stopped being updated at some point. When i guess the PIP PySide2 wheel option was made available.