ModuleNotFoundError: No module named 'OCC.Core'

[dumblob]

I've tried to use CQ editor with pythonocc 0.18.1 (I'm running python 3.7.4, but it fails with the following error:

master % 0$ python run.py
INFO:OCC.Display.backend:backend loaded: qt-pyqt5
Traceback (most recent call last):
  File "run.py", line 9, in <module>
    from cq_editor.__main__ import main
  File "/home/honza/del/CQ-editor/cq_editor/__main__.py", line 12, in <module>
    from .main_window import MainWindow
  File "/home/honza/del/CQ-editor/cq_editor/main_window.py", line 13, in <module>
    from .widgets.viewer import OCCViewer
  File "/home/honza/del/CQ-editor/cq_editor/widgets/viewer.py", line 14, in <module>
    from OCC.Core.AIS import AIS_Shaded,AIS_WireFrame, AIS_ColoredShape, \
ModuleNotFoundError: No module named 'OCC.Core'

It seems to be, that OCC.Core was removed after deprecation from pythonocc. Might it be the case, that CQ editor didn't accommodate to this change yet?

This effort is due to packaging for Arch Linux.

[adam-urbanczyk]

Pleas use our custom fork (BTW: 0.18.2 is the minimum required version):
https://github.com/CadQuery/pythonocc-core

The easiest way to install is using conda:

conda install -c cadquery -c conda-forge cq-editor

[dumblob]

The easiest way to install is using conda:

Unfortunately not so easy due to packaging compliance issues.

Any plans to use the standard (non-forked) version? Or vice versa - any plans to push your patches to pythonocc upstream?

[dumblob]

The upstream is currently working hard on 0.19 - shall be released pretty soon.

[adam-urbanczyk]

Interesting @dumblob , I did not know that. Will definitely take a look.

Regarding the issue, what is the exact complaint? You cannot use our custom build? FYI: the long term plan was to roll out our own bindings (cf. https://github.com/CadQuery/pywrap ).

[dumblob]

You cannot use our custom build?

True, I can't 😢.

The point is to be as much compatible with any upstream as possible as upstream stuff is usually already compiled, tested and available in distributions. Conda is unfortunately known as a package management system which doesn't play well (unlike npm, pip, go, etc.) with existing distribution package systems. I don't want to advocate immediately changing conda, but just point out that it's a bit unfortunate choice for CadQuery in my opinion.

Maybe #70 could be the solution (Flatpak is being adopted by important players like RedHat, elementary OS, Ubuntu, etc.).

FYI: the long term plan was to roll out our own bindings (cf. https://github.com/CadQuery/pywrap

Didn't know about that. Looks clean. But is it necessary (in terms of burning resources on that)? Maybe we could ask @rainman110 about their future plans with https://github.com/tpaviot/pythonocc-core/ whether any mutual alignment could be found.

[greyltc]

I see a 0.18.2 release here as of 7 hours ago. Does that work with this project?

[rainman110]

The swig generate modules were moved into the Core subpackage in the 0.18 release. If there is no OCC.Core, you probably have an older pythonocc release.

All release management and major decisions and development directions are made by @tpaviot.

I am solely interested in having a pythonocc version running for DLRs Tigl software. The conda packages a primarily made for the Tigl users to give a best possible user experience. That our repo has become the major source for pythonocc users is something else. We, the Tigl developers, will keep conda packages, as there is no comparable other way for the distribution.

A possible alternative for Linux are distribution dependent packages, that play well with the native package manager. Everything else is probably doomed to fail - or again similar to conda and brings its own ecosystem and libraries.

I am though happy to get ideas about other package management and distribution solutions.

[adam-urbanczyk]

We will most likely move to custom OCC bindings.