I’m working on some testing functionality for code that does some ParaView processing through Python. This is for a ParaView install from the download page and not a ParaView that I built myself. I’m not sure this matters though.
What I’m wondering is how feasible it would be to add a command line option to
pvpython that would print out the necessary environment variables (e.g. PYTHONPATH, LD_LIBRARY_PATH, and any others that are needed) that I’d need to set while running python so that I could import paraview into that python session. It may also be useful to include which Python version should be used as well.
That should be possible I would think.
As a workaround until that feature is added, you can get
PYTHONPATH should be necessary (for our binaries, probably Spack too, as rpaths are set up properly in these places). We could probably add it to
paraview-config as a
--python flag or something.
Please file an issue to track this.
Maybe I’m doing something wrong here but I tried running pvpython from PV 5.11 and adding the sys.path values from that into a regular Python3 session. I wasn’t able to import paraview when I added those pvpython sys.path values to the Python3 sys.path list.
Did I do something wrong?
Does Python have any relevant error messages? Does it even find
paraview/__init__.py or does it fail finding the compiled bits? If the latter,
LD_DEBUG=libs could help see where it is searching.
When I run pvpython from PV 5.11.1 on my RHEL8 machine I have the following output from sys.path:
[‘’, ‘/home/acbauer/Code/ParaView/ParaView-5.11.1-MPI-Linux-Python3.9-x86_64/lib/python39.zip’, ‘/home/acbauer/Code/ParaView/ParaView-5.11.1-MPI-Linux-Python3.9-x86_64/lib/python3.9’, ‘/home/acbauer/Code/ParaView/ParaView-5.11.1-MPI-Linux-Python3.9-x86_64/lib/python3.9/lib-dynload’, ‘/home/acbauer/Code/ParaView/ParaView-5.11.1-MPI-Linux-Python3.9-x86_64/lib/python3.9/site-packages’]
The error I’m getting is:
from .modules import vtkRemotingCore
ImportError: /home/acbauer/Code/ParaView/ParaView-5.11.1-MPI-Linux-Python3.9-x86_64/lib/python3.9/site-packages/paraview/modules/…/…/…/…/libvtkWrappingPythonCore3.9-pv5.11.so.1: undefined symbol: PyObject_CheckBuffer
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File “”, line 1, in
File “/home/acbauer/Code/ParaView/ParaView-5.11.1-MPI-Linux-Python3.9-x86_64/lib/python3.9/site-packages/paraview/init.py”, line 262, in
ModuleNotFoundError: No module named ‘_paraview_modules_static’
The full error message I’m seeing is in the attached file. Is this working for others by just modifying their
python3_import_paraview (119.2 KB)
It seems like the Python interpreter is not properly loading
libpython symbols such that modules can use them? What interpreter are you using?
This is with the system installed version of Python3 and the downloaded installer from ParaView v5.11.1:
[acbauer@dsrclxerd5621m ~]$ uname -a
Linux dsrclxerd5621m.localdomain 4.18.0-425.19.2.el8_7.x86_64 #1 SMP Fri Mar 17 01:52:38 EDT 2023 x86_64 x86_64 x86_64 GNU/Linux
[acbauer@dsrclxerd5621m ~]$ which python3
[acbauer@dsrclxerd5621m ~]$ python3 --version
This is not going to be able to load Python 3.9 modules (which is what the package is built with). Hence the undefined symbol (if it did have all the symbols, it would likely have crashed later because Python doesn’t keep the ABI stable enough to do that).
Got it. Thanks for tracking that down. I suppose then maybe some other useful information to be made available would be what version or versions of Python can be used. So I’m thinking something like:
$ pvpython --getsysteminformation
required Python version = 3.9
I’m sure you’ll come up with better command line arguments and formatting but hopefully you get the general idea.