fix(vtk-module): route remaining serializer imports through vtk_module

[akaszynski]

VTK_MODULE_NAME (added in 448530a) only works for part of trame. Three imports in the vtk serializers still hardcode vtkmodules, so a custom VTK build gets used for some of the code and stock VTK for the rest.

serializers/data.py shows it best. It sets vtk_module on line 7, imports from it on line 9, then goes back to vtkmodules four lines later:

vtk_module_name = os.environ.get("VTK_MODULE_NAME", "vtkmodules")
sys.modules["vtk_module"] = importlib.import_module(vtk_module_name)

from vtk_module.vtkFiltersGeometry import (...)
from vtkmodules.vtkCommonCore import vtkIdTypeArray   # missed

The other two are serializers/utils.py (from vtkmodules.util import numpy_support) and serializers/serialize.py (a bare import vtk).

What it looks like in practice. With a custom build and no stock vtk installed alongside it, the serializers don't import at all:

ModuleNotFoundError: No module named 'vtk'

If stock vtk is installed too, the import succeeds and you end up with objects from two VTK builds in one process. That fails later and further away, with errors like TypeError: GetGlobalId argument 1: and TypeError: ExportLegacyFormat argument 1:.

Fix. Same change as 090b504, applied to the three that were missed. serialize.py only used vtk for vtk.vtkCommand.DeleteEvent, so it becomes from vtk_module.vtkCommonCore import vtkCommand.

Backwards compatibility. The default is still os.environ.get("VTK_MODULE_NAME", "vtkmodules"), so nothing changes unless the variable is set. PyVista's jupyter/trame suite, three ways:

setup	result
stock vtk, variable unset, before this PR	56 passed
stock vtk, variable unset, after	56 passed
custom build + VTK_MODULE_NAME set, after	56 passed (all failed before)

vtk.vtkCommand is vtkmodules.vtkCommonCore.vtkCommand is True, so the serialize.py change is a no-op on stock VTK. It also takes import vtk out of the serializer import path, which pulls in all of VTK: 384 ms against 48 ms for vtkmodules.vtkCommonCore on this machine.

Left out. modules/paraview/protocols/mouse_handler.py and publish_image_delivery.py have the same hardcoded vtkWebCore import. I didn't touch them since I have no way to test against ParaView. Happy to include them if you'd rather do it in one go.

Tested on Linux with Python 3.12 and 3.13, against stock VTK 9.6.2 and a custom 9.6.2 build. Not tested on Windows, macOS, or ParaView.

---

Attribution: this was investigated and written with Claude Opus 5.0. I reviewed the work and helped point it at the root cause, but the model did most of the digging and verification. I don't want to pass it off as solely my own.

[akaszynski]

Hi @jourdain would appreciate a review on this as it's a blocker for pyvista/pyvista#8787

Thanks!

[Thibault-Pelletier]

@akaszynski thx for the PR.
It looks good to me. I'll let you address the pre-commit issue before merging!

[Thibault-Pelletier]

Merge pending pre-commit fix

[akaszynski]

Thanks @Thibault-Pelletier. Fixed in 5cef7f4.

The preamble is module-level code, so every import below it is E402. data.py already marks all of them including the relative ones; I had only marked the line I changed in serialize.py. Verified with the pinned ruff 0.15.10 against the repo config: clean, and ruff format --check reports no changes.

Worth flagging one thing for whenever this is released: pinning the serializer imports to vtk_module is what lets a custom build work end to end. PyVista's cvista integration goes from 118 failures to 4 with this branch installed, which is how the remaining three imports were found in the first place.