Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Certain imports break on script re-execution. #137

Closed
swolebro opened this issue Apr 2, 2019 · 5 comments
Closed

Certain imports break on script re-execution. #137

swolebro opened this issue Apr 2, 2019 · 5 comments
Labels

Comments

@swolebro
Copy link

swolebro commented Apr 2, 2019

I've got a strange error today after rebuilding the environment I use for FreeCAD and updating some of the Python packages. Specifically, numpy fails to import when re-executing a CadQuery script, though the first execution works fine.

I'm fairly confident the error is because of a change in numpy between v1.15.0 and v1.16.2. They added a numpy.core.overrides module, which appears to be mucking around with docstrings and executing code on import. That's generally a bad idea, but it does raise the question of what assumptions the CQ workbench is making about imports that don't play nicely with numpy's assumptions.

It looks like every time a CQ script is executed, all the modules it imports are deleted by this context manager. The point where this gets used makes a reference to other import styles causing non-standard execution, but in digging around, I wasn't readily finding any other info on it.

Mocking up the effect of that context manager in a regular Python terminal (with numpy 1.16.2) raises the same exception:

>>> import sys
>>> pre = set(sys.modules)
>>> import numpy
>>> for mod in list(sys.modules):
...   if mod not in pre:
...     del sys.modules[mod]
...
>>> del numpy
>>> import numpy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/swolebro/.conda/envs/freecad/lib/python3.6/site-packages/numpy/__init__.py", line 142, in <module>
    from . import core
  File "/home/swolebro/.conda/envs/freecad/lib/python3.6/site-packages/numpy/core/__init__.py", line 40, in <module>
    from . import multiarray
  File "/home/swolebro/.conda/envs/freecad/lib/python3.6/site-packages/numpy/core/multiarray.py", line 12, in <module>
    from . import overrides
  File "/home/swolebro/.conda/envs/freecad/lib/python3.6/site-packages/numpy/core/overrides.py", line 46, in <module>
    """)
RuntimeError: implement_array_function method already has a docstring

And either skipping the context manager in the CQ module or reverting to an older numpy works as a kludge fix to avoid it. Should the workbench be removing modules in this way? The Python docs sound kind of handwavy about how sys.modules works.

I'll readily admit that I'm not terribly versed in how Python imports (currently) work. Things have been changing so fast between Python 2.7 (where I started learning, a few years ago) and Python 3.7 (where we are today), that you'd almost think we're working with Javascript. I haven't been keeping on top of all of it.

@jmwright
Copy link
Member

jmwright commented Apr 3, 2019

@swolebro Thanks for the in-depth feedback on this. I wonder if it's related to #104

Should the workbench be removing modules in this way?

Probably not, but running the scripts in the FreeCAD Python environment has always been a challenge. The current solution was the lesser of all the evils (that I'm aware of).

I'll dig into this based on your information and post back here. Thanks again.

@jmwright
Copy link
Member

jmwright commented Apr 3, 2019

One other thing - CadQuery 2.0 and it's matching CQ-editor IDE are usable for many users at this point. We're still trying to fix things for Mac OS users. If you are interested in using PythonOCC instead of FreeCAD, those will be worth a look. It's the direction the project is headed in the future as well.

https://github.com/CadQuery/cadquery

https://github.com/CadQuery/CQ-editor

@swolebro
Copy link
Author

swolebro commented Apr 7, 2019

I'll try and brush up on the Python importlib documentation this week as well, and see if there's some better way to go about this. Can you recall any specific examples where not clearing the imported modules after running a script made FreeCAD act funny?

I heard that CadQuery was getting a rework with PythonOCC, but had not yet seen the new editor. That's interesting, and covers the biggest benefit of the workbench (the visual inspection window). I can think of three instances offhand where I've combined FreeCAD and CadQuery API calls into one script, but yeah, that's been infrequent at most, and was back when neither tool was as well fleshed out as they are today.

It's a really good tool you guys are building - an absolute godsend for those of us who are allergic to GUIs. I've been making sure to mention it on every Thingiverse thing I publish, with the code, to help people find out about it... and know that there are alternatives to OpenSCAD. (No offense to OpenSCAD, but Python is generally a much more useful and approachable way of doing things.)

@jmwright
Copy link
Member

jmwright commented Apr 8, 2019

Can you recall any specific examples where not clearing the imported modules after running a script made FreeCAD act funny?

I actually never saw the issue. I think that @fragmuffin is the only user who's ever reported it. I haven't noticed it during normal use.

I can think of three instances offhand where I've combined FreeCAD and CadQuery API calls into one script, but yeah, that's been infrequent at most, and was back when neither tool was as well fleshed out as they are today.

Probably best to at least give CadQuery 2.0 a try then since you're not bound too tightly to FreeCAD. We're not going to abandon FreeCAD users, but almost all of the future development effort is going to go into CadQuery 2.0.

It's a really good tool you guys are building - an absolute godsend for those of us who are allergic to GUIs. I've been making sure to mention it on every Thingiverse thing I publish, with the code, to help people find out about it... and know that there are alternatives to OpenSCAD. (No offense to OpenSCAD, but Python is generally a much more useful and approachable way of doing things.)

Thanks! Glad you've found it useful.

@jmwright
Copy link
Member

jmwright commented Dec 4, 2024

#158 relies on FreeCAD's macro editor and external IDEs, so this is going to become irrelevant.

@jmwright jmwright closed this as completed Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants