Pip installed Python packaged works on PythonSlicer terminal but not on Slicer console

Hello,
I would like to install a python wheel not available form Pypi that was built for Python 3.9.10, which is the same version I see on the Slicer Python console. As suggested in various other posts, I am installing the package using pip:

PythonSlicer.exe -m pip install package.whl

After installation I can correctly import the package and use it with the PythonSlicer command line, but if I try to do the same on the Slicer GUI Python Console, Slicer will freeze and crash.
If there anything specific that I could try to debug this issue? As mentioned, the python version of the wheel matches the PythonSlicer one, but I am not sure if I have to check anything else, e.g. other packages compatibility.
Thank you,
Luca

What are the Python package dependencies for your package? Any specific versions of those packages you require?

This is an issue on Windows? Have you tried any debugging on another platform?

Does your package rely on any other special considerations such as OS environment variables?

Hi James,
sorry for the lack of details.
I am working on Windows 11, the package is a slightly altered version of opensim, for which I built the libraries and the wheels here. The dependencies are included in the package, which needs to know where the dynamic libraries are, but I have specified that path as an environment variable.
Let me know if there is anything else that could be important to know and thank you for the quick reply!
Luca

Reviewing your whl build output, I suspect something to do with HDF5 which I saw was a dependency in your package.

See the following forum post with a similar issue of crashing within the application, but not when calling PythonSlicer directly:

Hi James,
I have built another wheel removing HDF5 and with the minimum amount of dependencies allowed by the main libraries (available here) and the issue persists.
I can smoothly load and use the package using the PythonSlicer console but the Slicer GUI still freezes when I try to do exactly the same using import opensim. I have tried few times and in one occasion the GUI was able to load the package and another time the GUI unfreezed with this error:

.
However, the package dlls are on the system Path variable (and PythonSlicer is finding them), so this is confusing because the outcome from the GUI looks inconsistent.
Is the GUI Python Console handling the module loading in the same way as PythonSlicer?

Are you able to build without the ezc3d package? Or if needed are you able to get ezc3d working on its own in Slicer? Last I remember ezc3d’s Python package was only Python 3.10+ compatible and Slicer is using Python 3.9.

One thing to do to get latest help would be to switch from Slicer 5.6.0 to latest Slicer stable 5.8.0.

@jcfr may have other thoughts but I would think there is some issues with this package and the app launcher that sets up the paths for things like the Python libraries to load.

Hi James, I have now tried with a wheel without ezc3d in Slicer 5.8.0…Again same outcome for both PythonSlicer (smooth loading the module) and Slicer GUI (frozen).
The new wheel is available here.

After a bit more testing I can confirm that when used through PythonSlicer.exe the loaded package works perfectly, which I assume it means that it is installed correctly and there are no incompatibilities. So my hypothesis is that the issue is due to a difference in how the GUI loads the packages compared to PythonSlicer. Is there a way to enforce the same loading behaviour?

So my hypothesis is that the issue is due to a difference in how the GUI loads the packages compared to PythonSlicer.

When importing a package from the Python Console [1] within the application, the Python interpreter is embedded in the overall Qt application, inheriting all Qt, VTK, ITK, and other symbols. As @jamesobutler originally suggested, an ABI mismatch is likely causing DLL loading failures.


  1. https://slicer.readthedocs.io/en/latest/developer_guide/python_faq.html#what-is-the-python-console ↩︎

Thank you Jean. This is not a familiar topic for me, I assume ABI is application binary incompatibility. Can this issue be overcome with some workaround? Building Slicer and the package on the same platform for example?

Luca - I was here to try and debug an extension Im working on… I couldnt help but notice your name, and then that the libraray is opensim! Im keen to see what you’re working on.