Why does the latest libpack provide Python 3.6 instead of 3.7

[flutefreak7]

I'm interested in using freecad alongside my existing python stuff which is currently using Python 3.7. Is there a compelling reason why freecad 0.19 is being built against 3.6 instead of 3.7? Thanks!

Sorry if this is the wrong place for this question.

[sgrogan]

I'm interested in using freecad alongside my existing python stuff which is currently using Python 3.7. Is there a compelling reason why freecad 0.19 is being built against 3.6 instead of 3.7? Thanks!

Sorry if this is the wrong place for this question.

It might be good if a Mod splits this, I think it will get traffic.
The main reason is that it's hard to get the whole dependency stack working together, If you read the whole development thread linked in the OP you will see where the problem came up.
FreeCAD itself supports PY3.7, in fact I'm working on updating the 0.19_pre Conda builds because they can use PY3.7, with QT5.9.

[flutefreak7]

Ok, that makes sense. A few months ago I had 3.7 working with conda-forge's FreeCAD 0.18. I'm having some trouble getting that working now, but I haven't quite tried everything... I just realized I might need to add Library/bin to sys.path or something.

One frustration I have is that my main python installation is pip-based since I had trouble with conda/pip interop breaking my conda installation. If I keep my main work in that pip-based installation, then the things I want to use freecad for have to have a dedicated miniconda install or environment just for those tasks. Then I'm left trying to utilize my personal code base with freecad while dodging pip-only dependencies to avoid inadvertently breaking my freecad conda environment. If I adopt freecad as a dependency of my library, it means I could have subpackages that can't all run on the same installation. blech.

If 0.19 installation or binary bundles go to 3.7 then I can just make FreeCAD a system dependency of my library and import it from a pip-based python installation. If it stays on conda, then I'm compelled to get all my codebase and dependencies working in a conda-only environment. Currently I think pyupdater is my main pip-only dependency.

[sgrogan]

Ok, that makes sense.

Yup to your whole post. It's just tricky getting it all to work together.
Right now I have a working 0.18.3 Conda environment that I am working on making portable. Once this works we should be able to provide weekly portable 0.19_dev Conda based builds based on PY3.7. We do this with the OSX(.dmg) and Linux(.AppImage). I'm behind on Windows
There is work to improve pip support for FreeCAD's python, but for compiled extensions it's very easy to break, probably similar to the issues you are having with Conda. Usually its easier to add them to the FreeCAD bundle.

EDIT: https://github.com/sgrogan/FreeCAD/rele ... /PY3.7-win WebGui doesn't work yet, but otherwise it should be good.

[apeltauer]

I'm interested in using freecad alongside my existing python stuff which is currently using Python 3.7. Is there a compelling reason why freecad 0.19 is being built against 3.6 instead of 3.7? Thanks!

Sorry if this is the wrong place for this question.

We had trouble with python 3.7. Some errors occurred during runtime. Then I switched to python 3.6 with no errors. This was the main reason...

[wmayer]

I was wondering why my debug builds are actually release builds when I use jom or ninja as build system. For testing purposes I tried an older Libpack and there it worked as expected.
So, I looked through your LibPack and found inside the file Shiboken2Config.cmake this line:

Code: Select all

SET(CMAKE_BUILD_TYPE "Release")

After removing this line debug builds are real debug builds now.

I will prepare a fix in FreeCAD so that people using the unfixed LibPack don't encounter the same issue.

EDIT:
It looks like the above line is required when building VS projects files because otherwise CMake raises a configure error.

[wmayer]

git commit cc59222aa