You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Starting a few days ago, the CI workflows to build the Docker and Singularity containers have been failing at the step where mayavi is installed. Some examples are here and here. In both cases, the line that fails is /venv/bin/pip install mayavi. The specific error message originates from
import vtk
File "/tmp/pip-build-env-woepris_/overlay/lib/python3.10/site-packages/vtk.py", line 5, in <module>
from vtkmodules.vtkWebCore import *
ImportError: libXrender.so.1: cannot open shared object file: No such file or directory
If I'm not mistaken, this error seems independent of the recent mayavi error discussed in #405 and #407.
Any ideas how to fix this? Should we remove mayavi from the docker and singularity containers, at least for now?
The text was updated successfully, but these errors were encountered:
I have noticed the same thing, and ran into it doing a fresh install with a student. I do not know what exactly caused it, but it is related to a dependency conflict originating from VTK and the gui (pyQT5 or 6?).
I solved it by changing the order of installs. Mayavi is very picky and fragile, if you install it first then a matching VTK and gui version will be chosen, but if a VTK version is already present because it was installed by simsopt, this error occurred for me.
I would be in favor of removing it from the containers if this doesn't fix it. I constantly have headaches keeping it running on my ArchLinux system, Mayavi keeps breaking in unexpected and new ways when packages are updated.
Starting a few days ago, the CI workflows to build the Docker and Singularity containers have been failing at the step where mayavi is installed. Some examples are here and here. In both cases, the line that fails is
/venv/bin/pip install mayavi
. The specific error message originates fromIf I'm not mistaken, this error seems independent of the recent mayavi error discussed in #405 and #407.
Any ideas how to fix this? Should we remove mayavi from the docker and singularity containers, at least for now?
The text was updated successfully, but these errors were encountered: