Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#74455 - [paraview] pvpython cannot import non-standard-library system modules (e.g. matplotlib, PIL)
Attached to Project:
Community Packages
Opened by Jakub Klinkovský (lahwaacz) - Tuesday, 12 April 2022, 14:12 GMT
Last edited by Bruno Pagani (ArchangeGabriel) - Saturday, 23 July 2022, 19:29 GMT
Opened by Jakub Klinkovský (lahwaacz) - Tuesday, 12 April 2022, 14:12 GMT
Last edited by Bruno Pagani (ArchangeGabriel) - Saturday, 23 July 2022, 19:29 GMT
|
DetailsSince the paraview-wrapper script was introduced, importing non-standard-library Python modules in pvpython does not work. For example, matplotlib:
$ pvpython -c "import matplotlib" Traceback (most recent call last): File "<string>", line 1, in <module> ModuleNotFoundError: No module named 'matplotlib' Adding the /usr/lib/python3.10/site-packages path explicitly to PYTHONPATH seems to fix the issue: $ export PYTHONPATH=/usr/lib/python3.10/site-packages $ pvpython -c "import matplotlib" This should be solved in the paraview-wrapper script. When matplotlib is not available in pvpython, various rendering issues may appear, e.g. https://gitlab.kitware.com/paraview/paraview/-/issues/21352 (that is probably direct consequence of this bug) |
This task depends upon
Closed by Bruno Pagani (ArchangeGabriel)
Saturday, 23 July 2022, 19:29 GMT
Reason for closing: Fixed
Additional comments about closing: paraview 5.10.1-9.
Saturday, 23 July 2022, 19:29 GMT
Reason for closing: Fixed
Additional comments about closing: paraview 5.10.1-9.
/opt/paraview/bin/pvpython -c "import sys; print(sys.path)"
['', '/usr/lib/python310.zip', '/usr/lib/python3.10', '/usr/lib/python3.10/lib-dynload']
$ python -c "import sys; print(sys.path)"
['', '/usr/lib/python310.zip', '/usr/lib/python3.10', '/usr/lib/python3.10/lib-dynload', '/home/lahwaacz/.local/lib/python3.10/site-packages', '/usr/lib/python3.10/site-packages']
The difference seems to be due to the 'site' module: https://docs.python.org/3.11/library/site.html
When I run python -S, the sys.path becomes the same as that of pvpython:
$ python -S -c "import sys; print(sys.path)"
['', '/usr/lib/python310.zip', '/usr/lib/python3.10', '/usr/lib/python3.10/lib-dynload']
To get the same sys.path (almost) in pvpython as in default python, I need to
$ /opt/paraview/bin/pvpython -c "import site; site.main(); import sys; print(sys.path)"
['/home/lahwaacz', '/usr/lib/python310.zip', '/usr/lib/python3.10', '/usr/lib/python3.10/lib-dynload', '/home/lahwaacz/.local/lib/python3.10/site-packages', '/usr/lib/python3.10/site-packages']
It seems that for some reason pvpython behaves as if the -S flag was specified. Also note that the same goes for vtkpython (from the vtk package) so it might be an upstream issue.