This concerns me and makes me weary of this new override mechanism, though I think there is a path here where we can cross pollinate and make these support modules robust and flexible so that community projects like PyVista and direct efforts from VTK can thrive together.
Right, PyVista’s core API is handling quite a lot of things in addition to just wrapping the data model: supporting FileIO, type conversions, filters, etc. – all things that others may want to do differently, such as with a full on VTK pipeline (PyVista’s core API only chains operations together as of today). PyVista’s data model is tightly coupled to those additional features making PyVista incredibly flexible and powerful yet making that migration back to VTK tough and probably not worth our time. So yes, I understand why this new data model in VTK is being pushed, but my wishful, starry-eyed part still hopes for more direct embrace of PyVista as it does indeed solve all of the original goals
I’d love to see us converge and for much of PyVista’s core API “ported back to VTK” too, but I’m skeptical that upstream in VTK is the best place for this. I want to advocate that VTK consider hosting the Python wrappings in a standalone repository and as a separately installable package. The barrier to contributing to VTK’s repository is high and the release cycles are not flexible enough for what is required to iterate on this new data model to get it to a point where it is stable enough to encourage wide adoption. And to paraphrase someone from the PyVista community recently, we’re happy to contribute to this new Python API and volunteer our efforts (free labour) but we need some give and take here and to reduce the barriers to contributions.
The reality is that this new data model API, while very promising and deserves a chance to prove itself, is very new, unproven, and showing shortcomings that are affecting downstream project(s). For these reasons, I’d like to strongly advocate that VTK change these overrides to be opt-in for now. Then if a downstream Python packages want’s to opt in, they could either have a simple import to trigger this or we could make a mechanism directly in VTK so that downstream packages could register an entrypoint for these overrides.
If the compromise is to use unregister_vtk_module_dependencies in PyVista, then I think that is fine, but I’d like to see assurances (in the form of tests in VTK’s code) that this new data model isn’t required to use VTK in Python until it reaches a level of stability we are all comfortable with (perhaps these tests exists?)
I too am excited for this prospect and I truly believe this is in reach, though I think it will require a lot of coordination and a champion to lead this, however, I’m afraid there may not be anyone from PyVista with the capacity to take this on at this time.