Importing FreeCAD in an external project environment

[Mow]

Hello everybody,
Thank you so much for your time. I want to use FreeCAD in my project environment to generate .stl shape directly from my project Environment (IDLE Pycharm). I have read many post in forum about using FreeCAD as external library and tried every solution i found.
This is the problem: the only way i can run this line: ''Import FreeCAD'' without errors is to navigate the Interpreter of project (in Pycharm) to the ''Python'' which is coming with FreeCAD's package itself located here:
/Applications/FreeCAD.app/Contents/Resources/bin/python
otherwise i get this error:

Code: Select all

Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)

The code i try with:

Code: Select all

import sys
path = '/Applications/FreeCAD.app/Contents/Resources/lib'
sys.path.append(path)
import FreeCAD

This means that i should set the default Interpreter of my project to the ''Python'' of FreeCAD so that i can use it. But this is not practical because i have many other libraries in the default Interpreter of my project.
Unfortunately i'm no expert in virtual environments, conda, compiling etc.. I would be so thankful for any suggestion to solve this issue:
Is this the only way i can import FreeCAD externally in mac?
is it possible to merge the python coming with FreeCAD's package into my default interpreter package?

OS: macOS Sierra (10.12)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.16110 (Git)
Build type: Release
Branch: (HEAD detached at 0.18.1)
Hash: f7dccfaa909e5b9da26bf50c4a22ccca9bb10c40
Python version: 3.6.7
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Best,

[ickby]

This sound like a version mismatch between your system python and FreeCAD python. An ABI interface change would lead to such errors. In your FreeCAD info we see it uses 3.6.7, could you check what your system version is? If they do not match it is basically impossible to use freecad as library in a system python, so you would need to change the systme python version, or recompile freecad with your system python. but I have no idea how to do that on a mac.

[Mow]

This sound like a version mismatch between your system python and FreeCAD python. An ABI interface change would lead to such errors. In your FreeCAD info we see it uses 3.6.7, could you check what your system version is? If they do not match it is basically impossible to use freecad as library in a system python, so you would need to change the systme python version, or recompile freecad with your system python. but I have no idea how to do that on a mac.

Thank you Ickby. I also think there should be such a problem. This is my system version:

Code: Select all

Python 3.7.3 (default, Mar 27 2019, 16:54:48) 
[Clang 4.0.1 (tags/RELEASE_401/final)] :: Anaconda, Inc. on darwin
Type "help", "copyright", "credits" or "license" for more information.

[wmayer]

Maybe it's not the most elegant solution but instead of trying to directly load the FreeCAD module you can check if running FreeCADCmd works for you. So, you write your Python code to generate the .stl file but then from within your project environment use subprocess.Popen(["FreeCADCmd", "make_stl_shape.py"])

[looo]

Python 3.7.3 (default, Mar 27 2019, 16:54:48)
[Clang 4.0.1 (tags/RELEASE_401/final)] :: Anaconda, Inc. on darwin

Please try install FreeCAD with anaconda to guarantee compatibility between packages. The best way is to create a new environment:

Code: Select all

conda create -n freecad freecad -c conda-forge

or if you want to have a more recent version use:

Code: Select all

conda create -n freecad freecad-c freecad/label/dev -c conda-forge

and always check which packages are going to be installed (should be python3.7, qt5.6)

[Mow]

Please try install FreeCAD with anaconda to guarantee compatibility between packages. The best way is to create a new environment:

Thank you so much. I still get the same error. I created a new conda environment with the first code you suggested:

Code: Select all

conda create -n freecad freecad -c conda-forge

now the version of FreeCAD's python and the python in conda environment are both 3.7.3:
OS: macOS Sierra (10.12)
Version: 0.18.16110 (Git)
Hash: f7dccfaa909e5b9da26bf50c4a22ccca9bb10c40
Python version: 3.7.3
Qt version: 5.6.2
Then I created a new project in pycharm and for Interpreter i navigated to the python 3.7.3 which is coming with new conda environment (image below). Then i tried to import FreeCAD and i get the same error:

Code: Select all

import sys
path = '/Users/Adel/miniconda3/envs/freecad/lib'
sys.path.append(path)
import FreeCAD

Code: Select all

Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)

[looo]

ups. Now I remember having problems with starting FreeCAD from jupyter-lab on osx too. Sorry for my misleading advice.

This could be related to some changes made by conda-devs (static vs shared python linking) But I am not sure.

[wmayer]

According to the CMake code there are many checks to determine the correct Python version on macOS. If I understand the code correctly then there can be up to three different Python versions on that system:
the version installed by HomeBrew or MacPorts or a system version which should be avoided. And with anaconda you may get even a fourth Python version?

I wonder of how much it can be a problem if FreeCAD was built with HomeBrew but on the target system MacPorts is used or vice-versa.

[looo]

According to the CMake code there are many checks to determine the correct Python version on macOS. If I understand the code correctly then there can be up to three different Python versions on that system:
the version installed by HomeBrew or MacPorts or a system version which should be avoided. And with anaconda you may get even a fourth Python version?

I wonder of how much it can be a problem if FreeCAD was built with HomeBrew but on the target system MacPorts is used or vice-versa.

I have only freecad via conda so this should not be the problem.

ps.: https://gitter.im/conda-forge/conda-for ... 2a951ff375

[looo]

I remember netgen also crashed because python was dynamical linked [1]. I understood it this way:
If a library is an extension module (c++ / c / fortran library with python bindings) we need to not link python at all. If an executable embeds python we need to link the DSO (dynamic shared object). Regarding conda-devs this is the general case and often done incorrectly. Normally this doesn't lead to problems, but currently on osx we are seeing crashes because of this.

In [1] I had to modify the cmake-scripts of netgen to avoid the runtime crash.

So what we need to do: remove the python-library linking for all modules but not for the executable. I did it this way for netgen [2].

btw.: This could be a general problem of osx builds. So there is a chance this will also solve other issues.

ps. I will try this suggestion with a patch for the conda-builds.

[1]https://github.com/conda-forge/netgen-f ... -443008998
[2]https://github.com/NGSolve/netgen/pull/ ... 53c7291R32