Py2ectomy

[kkremitzki]

According to https://pythonclock.org/ we have about 4 months of Python 2 left, so it may be time to start talking about cutting Python 2 out of FreeCAD since 0.19 will almost surely be released after Python 2 end of life. The idea is that anyone who still needs Python 2 support could use 0.18.x.

This would in effect mean switching to Py3/Qt5 as a default and removing code targetting Qt 4 and Python 2, turning off the Daily PPA's Python 2 builds, and uploading a Python 3 only 0.19~pre package to Debian Experimental. (Can't upload to Unstable because then we wouldn't have a stable release in Ubuntu 19.10 and possibly 20.04 LTS if we don't release 0.19 in time.)

Thoughts?

[DeepSOIC]

Qt4 is still quite a bit more stable for 3d rendering. If we can't easily make Py3+Qt4 combo, I think the support of Py2 should be continued for a while.

[kkremitzki]

Ah, that's a good point. Python 3 + Qt 4 support might not be that difficult but I hadn't expected there to be any demand. Putting in the effort to try to get that working almost seems worth it though to move forward with Python 3 only. I wouldn't mind trying to get that working for the Debian family stuff, but I am curious what some of the other packagers and developers might think.

[looo]

I wouldn't mind trying to get that working for the Debian family stuff, but I am curious what some of the other packagers and developers might think.

Qt4 is only partially supported in conda-forge (no webkit, older deps) so some work would be necessary to create a qt4/py3 package. (Locally I have one qt4/py3 build installed, but this is quite old.)

[DeepSOIC]

...I have one qt4/py3 build installed...

That's very good news to me, as I was under impression that Qt4+Py3 is almost impossible. I would love to see Py2 go away, because I can't use most of the nice features of Py3 due to the requirement of supporting Py2 in my workbenches.

[kkremitzki]

At least from the Debian side, it should be easier now since the newest Pivy is packaged. At best it will be a change of dependencies in the SoQt and Pivy packages' debian/control files and a change of build flags in debian/rules, plus rebuilding them, and it may even be a matter of simply rebuilding Pivy and using the old Coin/SoQt packages. (Although this would cause the libexpat SVG bug to re-appear.)

[looo]

At least from the Debian side, it should be easier now since the newest Pivy is packaged. At best it will be a change of dependencies in the SoQt and Pivy packages' debian/control files and a change of build flags in debian/rules, plus rebuilding them, and it may even be a matter of simply rebuilding Pivy and using the old Coin/SoQt packages. (Although this would cause the libexpat SVG bug to re-appear.)

Never expect something to be easy in packaging world But it would be very nice if you can achieve a qt4/py3 package for debian/ubuntu. Btw.: If you can somehow split the soqt-dependent part of pivy it's not mandatory to rebuild pivy and using latest coin should be possible.

Regarding conda:
I guess a little bit of work is needed to get it done, but looks like it is at least possible to get consistent packages (using occt7.2):
linux: https://circleci.com/gh/looooo/freecad- ... build-link
windows: https://ci.appveyor.com/project/looooo/ ... s/26630807

[yorik]

At the moment maintaining py2 support doesn't cost us much, outside packaging of course.

I think we should maintain it as long as it's not unpractical for us, I'm sure there are dozens of users on old distros out there, and when a software says "from now on we drop support of XX or YY" it's always a bitter news... And we care for people on old distros, dont we

I think we can progressively stop providing py2 packages. Then the use of py2 FreeCAD will progressively reduce, then the problem will become less and less important...

[looo]

qt4.8 vs qt5.9 vs qt5.12:
https://vimeo.com/353533116

qt4 wins. Any ideas why qt5 is slower?