For shared VTK builds, a shared libpython is needed. If you build Python yourself, use --enable-shared when you configure it.
I never build python, I just use the system install. However Iām going to clean my python environment, itās likely I have different versions around and confusion is the result.
Hi Will, thereās something funny going on because ā/usr/local/lib/libpython3.6m.aā is not where ubuntu puts libpython. The systemās python should be in ā/usr/libā.
Iām building from scratch, Iāve removed a lot of junk. Thanks for the help, Iām hopeful that this will fix it.
Iām good now, my python environment needed some love. Thanks,
@dgobbi as a first step, do you see any issues replacing import vtk in the Python examples with import vtkmodules.all as vtk?
My thinking here is that users using IDEs will get a list of options etc., (which they donāt get with just import vtk), and this will facilitate learning/comprehension when experimenting.
The second step would be to gradually replace import vtkmodules.all as vtk with just the relevant imports. This does bring it more into line with C++ usage.
I think thatās a great idea.
To satisfy my own curiosity, I tried it with vim-jedi but its autocompletion was slooow for the vtk module (too much stuff inside, must not cache efficiently). Importing just the needed modules was definitely faster.
Thanks, Iāl do it.
There is also a significant improvement in importing just the needed modules in Windows!
Well, Linux loads executables and shared libraries/modules by memory-mapping. So loading a library/module for a second time is essentially free, even if the module is huge. The module persists in RAM until memory pressure causes it to swap out.
This issue is ātrackingā the porting of the test suite as well.
@ben.boeckel At least we now have a script that users can use to get a list of the needed modules.