Why is vtkmodules.util.data_model overriding by default?

Development
1

In VTK 9.4, it looks this the new Python wrappings originally proposed in More pythonic interface / closer to numpy are now the default imposed on all Python VTK users:

>>> from vtkmodules.vtkCommonDataModel import vtkPolyData
>>> vtkPolyData()
<PolyData(0x609f2ae8b6b0) at 0x7c60007dbd00>
>>> p = vtkPolyData()
>>> p.__module__
'vtkmodules.util.data_model'

I’m curious if this decision was intentional and if someone (cc @berk.geveci) could speak to the benefits of this new API and the reasoning behind opting all VTK Python users into this new API. It seems to have been done intentionally here I believe.

This decision is causing quite a few headaches for downstream projects like PyVista as it is a breaking change. To mitigate this, we’re just going to have to forcibly override to PyVista classes but I’d really like to prevent a scenario where this new module in VTK and PyVista are competing to override the users environment.

2

cc: @jaswantp

3

The behavior is optional. So even though it is the default, it can be turned off (though the mechanism to do so is undocumented and not very clean):

>>> import vtkmodules
>>> vtkmodules.MODULE_MAPPER
{'vtkCommonDataModel': ['vtkmodules.util.data_model'], 'vtkCommonExecutionModel': ['vtkmodules.util.execution_model']}
>>> vtkmodules.MODULE_MAPPER = {}
>>> from vtkmodules.vtkCommonDataModel import vtkPolyData
>>> vtkPolyData.__module__
'vtkmodules.vtkCommonDataModel'

There is a risk that as time goes on, more and more of the VTK support modules will rely on these default overrides, essentially making them non-optional.

1 Like
4

It would have been a wonderful success story of open source if VTK embraced community efforts like PyVista’s years of development on this exact thing instead of starting something from scratch and breaking said community efforts. It makes me sad (and a bit frustrated), but I guess I get it… PyVista is “PyVista” not “VTK”…

1 Like
5

@banesullivan if you recall we tried to extract the data model from PyVista and make it into VTK core. But that didn’t work out as PyVista was doing more than just dealing with Numpy. The original idea was to enable PyVista to focus on its plotting API and port back the data model to the VTK side.

With the updated wrapper, the only thing that is missing is the numpy handling (but only when numpy is available). If those are incomplete or missing something, people can still contribute to them. But those Python add-on should remain tiny as they should just focus on the numpy/array mapping at the VTK core side.

Same goes with the undocumented register_vtk_module_dependencies which we could add its counter part to unregister_vtk_module_dependencies or clear_ vtkmodule_dependencies. But for now the idea was to allow the community to add their own override if they wanted, rather than removing the “VTK” ones.

Anyway, I’m expecting some transition happening with 9.4 but ideally the migration toward a single data model between PyVista and VTK could truly happen for 9.5?