Building with Python 3, Qt 5 on Ubuntu 18.04

[ian.rees]

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.

Ha! Then what were you on about, saying it was easy to do... Anyway, it doesn't matter.

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)

Sweet! Not sure I'll have time to try it out tonight, but will in the next few days. Thanks!

[kkremitzki]

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.

My first build had all those options set, but I was checking the freecad-python3-git Arch Linux PKGBUILD and noticed it was quite simplified, so I gave it a shot, and it seemed to behave the same as my original build. A pleasant surprise.

I should mention that I changed src/Gui/WidgetFactory.cpp and replaced PyQt5 with PySide2 here because I didn't want to install PyQt5:

Code: Select all

   341 #if QT_VERSION >= 0x050000
~  342     module = PyImport_ImportModule((char*)"PySide2.QtWidgets");
   343     if (!module)
~  344         throw Py::Exception(PyExc_ImportError, "Cannot load PySide2.QtWidgets module");

Perhaps that should be updated to first try PySide2 and then fall back to PyQt5? Then once PySide2 is available on enough platforms we can remove the fallback.

[triplus]

Ha! Then what were you on about, saying it was easy to do... Anyway, it doesn't matter.

OK.

@kkremitzki

Whatever makes it easier and more streamlined has my vote.

Perhaps that should be updated to first try PySide2 and then fall back to PyQt5? Then once PySide2 is available on enough platforms we can remove the fallback.

We don't support PyQt5 at all. We used PyQt and migrated to PySide in the past. Due to some licensing concerns. Therefore if FreeCAD wants to use PyQt/PyQt5 in any place ATM. That basically is a bug and should be replaced with PySide/PySide2 logic altogether.

[ian.rees]

Sorry about my delayed response, but I've finally gotten around to working on this a bit more.

On my system, installing libpyside2-dev doesn't install a cmake file for Python3, so cmake complains that it can't find /usr/lib/x86_64-linux-gnu/cmake/PySide2-5.11.0/PySide2Config.cpython-36m-x86_64-linux-gnu.cmake . I'd think the pattern would have a libpyside2-py3-dev package which would cover this case, but that doesn't seem to exist. In the mean time, I've made a Python3 cmake file following the Python2 pattern with updated paths - seems to work OK now.

Also had to make the change like Kurt mentioned, to pull in PySide2 instead of PyQt5 - will go make a PR to bring that change in shortly.

[wmayer]

Perhaps that should be updated to first try PySide2 and then fall back to PyQt5? Then once PySide2 is available on enough platforms we can remove the fallback.

When you look at the function PythonWrapper::fromQWidget then we use the C++ interface of shiboken/PySide. The C++ interface hasn't changed with shiboken2/PySide2 (at least with the version I built in December 2016).

Then in the lines 311-327 there is also a way to access shiboken/PySide using its Python interface. This code at the moment is "blind" but I think it might be best to access PySide this way as it simplifies the build process of FreeCAD. At configure time we don't have to check for the existence of it and also the built FreeCAD libraries won't link against the shiboken/PySide libraries.

IMO we should first try to load the shiboken/PySide Python module and if this fails try sip/PyQt.

FYI, there exists a tiny wrapper called QtPy (which is part of the Spyder IDE) and by using it we could simplify a lot of things in our pure Python workbenches (Arch, Draft, ...). So, this way we could make FreeCAD pretty much independent of the installed Qt Python wrapper and use this one that is installed on the system.

[ian.rees]

IMO we should first try to load the shiboken/PySide Python module and if this fails try sip/PyQt.

FYI, there exists a tiny wrapper called QtPy (which is part of the Spyder IDE) and by using it we could simplify a lot of things in our pure Python workbenches (Arch, Draft, ...). So, this way we could make FreeCAD pretty much independent of the installed Qt Python wrapper and use this one that is installed on the system.

Either of those sounds good. Feel free to ignore/delete my PR in favour of a more comprehensive fix - I just assumed the PyQt was left over from when we were first looking at Qt5 but well before PySide2 was usable.

[damian]

Good morning:

FYI, there exists a tiny wrapper called QtPy (which is part of the Spyder IDE) and by using it we could simplify a lot of things in our pure Python workbenches (Arch, Draft, ...). So, this way we could make FreeCAD pretty much independent of the installed Qt Python wrapper and use this one that is installed on the system.

I've been using Spyder the last two years and my experience is pretty satisfactory. No problems, no crash. Services exactly which I need.
Now I need to do some dialogues and QtPy is a perfect solution for me in this dependencies jungle. I'll try it.
Thank you

[Jee-Bee]

some time ago I had some Qt related trouble. When I imported Qt it crashes. But probably it was related that I used Qt5 and my spyder runs at Qt4 at that moment.