Porting to python3

[NormandC]

Kurt is making a lot of headway in this regard.

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

[kkremitzki]

Kurt is making a lot of headway in this regard.

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

Indeed, the main blocker PySide 2 looks like it's going to fall soon. Now that it's been fully released I decided to revisit the packaging. Upstream has combined everything into a mono-repo which makes things a little easier. I started hacking away at the package but was getting failures at the end of the build process (about 90 minutes, I don't think the automatic multi-core build is working!). Luckily, I found Raphaël Hertzog had filed this bug against upstream which includes a patch, and suggests he's making headway on the official package.

In the meantime, with that patch I seem to have a working, lazy-man's single python3-pyside2 package. (In other words, the package isn't properly split up into several binaries like this.) It's good enough for some further experimentation with my python3-pivy package but not yet good enough for a Python 3/Qt 5 PPA build.

[triplus]

@looo

I tested your latest AppImage on Ubuntu 14.04 and i don't experience the libTKMath.so.7: undefined symbol issue anymore. When trying to enter the Sketcher workbench. After i tested the procedure to create an AppImage from Conda packages. I was able to succeed by combining your instructions and with some additional search for clues on the web. Produced AppImage still has libTKMath.so.7: undefined symbol error on Ubuntu 14.04. Therefore i am guessing you just didn't update the procedure to create the AppImage on your GitHub and that is causing the difference.

@NormandC & @kkremitzki

Good to hear that. The truth is if Py3 AppImage based on @sgrogan personal PPA wouldn't have the issue when trying to enter the Sketcher edit mode. It likely would already suffice for now. We just want to get a wider end user base reporting potential Py3 issues. Before i guess Py2 reaches EOL. And everything done in addition to support/improve Py3 situation on the PPA in the future would therefore likely propagate nicely. But there is one problem. I guess. Making Py3 builds to work on PPA will happen sooner or later. But i am not all that sure Py3/Qt5 builds will ever be available for Ubuntu 14.04. Therefore PPA based Py3/Qt4 AppImage is an option for the near future. If we want to have Py3/Qt5 AppImages. The nearest option ATM is to reuse work @looo has already done.

Therefore the question for you @looo. You likely love packaging (and biking). Have been doing that for a while now and will likely continue to do that in the future. If we reuse your Conda work for Py3/Qt5 AppImage now. Are you prepared to work on reported issues? That is end users will for sure come and say i downloaded the latest Py3/Qt5 AppImage and when trying to do this i got this issue instead. Are you prepared to address such issues? To give it some thought and to see if the issue can be resolved in some straightforward fashion or not. If you are prepared to do that i feel that we should give it a try and see how it goes. And to continue to use PPA as a basis for Py2/Qt4 AppImages for now.

[looo]

Produced AppImage still has libTKMath.so.7: undefined symbol error on Ubuntu 14.04. Therefore i am guessing you just didn't update the procedure to create the AppImage on your GitHub and that is causing the difference.

https://github.com/looooo/freecad_conda ... ef78086e56

That is end users will for sure come and say i downloaded the latest Py3/Qt5 AppImage and when trying to do this i got this issue instead. Are you prepared to address such issues? To give it some thought and to see if the issue can be resolved in some straightforward fashion or not.

I am doing this already for conda-packages, but the download numbers compared to appimages are not that high. So I expect more issues reported. Most of them wil be python3-related.


Maybe we can reactivate the circle-ci-stuff to build FreeCAD with conda-packages automatically and afterwards create an appimage. This shouldn't be too hard. The difficult part is the upload of the appimage, but I guess you have some experience with this task, so maybe you can give some instructions on how to solve it.

[triplus]

I am doing this already for conda-packages, but the download numbers compared to appimages are not that high. So I expect more issues reported. Most of them wil be python3-related.

Yes exactly. As you are already doing this and likely will continue to invest effort in the foreseeable future. It makes sense to try out the Conda option first. And to see how it will pan out.

Maybe we can reactivate the circle-ci-stuff to build FreeCAD with conda-packages automatically and afterwards create an appimage. This shouldn't be too hard. The difficult part is the upload of the appimage, but I guess you have some experience with this task, so maybe you can give some instructions on how to solve it.

What is the current situation when it comes to FreeCAD (daily) package available from Conda? How often does it get updated ATM? On a daily basis or less often? Are you doing that manually or the procedure is automated?

As for the AppImage itself yes i do plan to give it a try in the next two days. To try providing Conda based Py3/Qt5 AppImages for now. In the past macOS packagers invested heavily in this area and that work can be reused. We have discussed all available options we have ATM in the past two weeks in depth. Now i guess if there are no objections the time has come to try to make it happen.

[looo]

How often does it get updated ATM? On a daily basis or less often? Are you doing that manually or the procedure is automated?

New builds for Linux, osx, win are uploaded when a PR is merged here: https://github.com/conda-forge/freecad-feedstock

I also provide manually builds for the freecad-channel, but currently this doesn't happen that often.
So using circle-ci to build latest fc master and bundle the package into a appimage would be a nice idea. Some pinnings have to be changed (occt7.3 + smesh and netgen build with occt7.3 are already available) and the local build on the ci must be selected as freecad-package to be bundled.

I have made a packaging plan which list the main challenges for freecad-related packages in the next time. But for the appimage, it should be possible to use always working older dependencies. https://github.com/FreeCAD/FreeCAD_Cond ... ng_plan.md

[triplus]

What about the version information? Currently shallow clone is being used and therefore version information isn't available. Do you feel this could be addressed soonish or at all?

P.S. If not i have seen a date is being added to the FreeCAD.Version() information. And i guess i could use that for now. As on Releses page user needs to know if current AppImage was already downloaded in the past or not. And to determine that in some straightforward way. In addition some could complain (when providing or requesting version information) for not being complete.

[looo]

I thought version info is working for conda-forge package, but I am not sure.
If building the latest master with circle-ci I guess this will be solved anyway.

[triplus]

No. ATM it's not working (likely shallow clone is being used). Will leave that part for later. When version information will be made available. And for now will just use some generic name.

[looo]

I added the appimage-creation to the circle-ci stuff. Also I changed from creating the environment for the appimage from specific version to an environment which is created from resolving the dependency tree. I guess quite a few dpeendencies have to be deleted afterwards to reduce the size of the appimage.

No upload is done yet.

https://github.com/looooo/FreeCAD/blob/ ... ild.sh#L52
https://circleci.com/gh/looooo/FreeCAD/231

edit: I don't think this will work at first try