@ben.boeckel, would it be possible (or perhaps it is already happening) to host the CI-generated wheels from this branch on the pip package registry so that downstream packages could test against this?
Vedo does not inherit classes from VTK
There seems to be a number of places where Vedo directly inherits from VTK classes (I would add links here but I keep getting the following warning):
MayaVi generates its own set of classes
Mayavi generates its own "traited" VTK classes if I recall correctly. To be honest I don't understand anything about this but my impression is that it uses inheritance in its wrapping... I think it would be worth building and running Mayavi against this branch to see if there are any impacts. I gave this a try and while I was able to build, install, and use Mayavi against the latest VTK wheels on PyPI, I was not able to build Mayavi's TVTK when using this branch (though this could be a me problem).
I think more due diligence and engagement with both Mayavi and Vedo is needed here.
I'm hoping that addressing the compatibility with PyVista is as simple as the inheritance order/scheme that @berkgeveci outlined in this discussion, but I still want to exhibit a high degree of caution considering how many downstream users and projects could be affected by these changes.
I'm really excited to see this work! This is going to be a great quality of life improvement for many Python VTK users and I'm ecstatic to see the keyword arguments for class instantiation 🤩
I have cloned and built this branch locally, and this is causing quite a few failures when paired with PyVista out the door. I don't have a much free time to dive into this, but I hope as a part of the broader Python-VTK community, we can work together to minimize the affects of this drastic change.
With that said, it is my opinion that as it stands, these changes should be considered breaking changes to Python VTK API. I, as a part of the PyVista community, would greatly appreciate that merging this PR is taken with the utmost caution and care as it will affect many downstream projects including Mayavi, Vedo, and PyVista which have extensive users and downstream dependencies themselves.
The following works before VTK 9.3 and is now broken.
This is an issue for PyVista's wrapping of vtkMultiBlockDataSet
and is causing testing failures in https://github.com/pyvista/pyvista/pull/4688
import vtk
source = vtk.vtkSphereSource()
source.Update()
a = source.GetOutput()
source = vtk.vtkConeSource()
source.Update()
b = source.GetOutput()
blocks = vtk.vtkMultiBlockDataSet()
blocks.SetNumberOfBlocks(2)
blocks.SetBlock(0, a)
blocks.SetBlock(1, b)
copy = vtk.vtkMultiBlockDataSet()
copy.ShallowCopy(blocks)
# Works prior to VTK 9.3
assert id(copy.GetBlock(0)) == id(a) # Should have same ID since ShallowCopy
assert id(copy.GetBlock(1)) == id(b) # Should have same ID since ShallowCopy
In hindsight, after a lot of digging through the threads and PRs around this. I think this is fine... re-closing.
I am re-opening this as I feel this was closed and dismissed hastily with new unresolved conversations. In my opinion, this deprecation was too aggressive, and something should be done to either warn/alert downstream users of this unexpected breakage or correct the now broken implementation
@mwestphal, you're a maintainer -- so feel free to dismiss and close again if I'm off-base.
The following works before VTK 9.3 and is now broken.
This is an issue for PyVista's wrapping of vtkMultiBlockDataSet
and is causing testing failures in https://github.com/pyvista/pyvista/pull/4688
import vtk
source = vtk.vtkSphereSource()
source.Update()
a = source.GetOutput()
source = vtk.vtkConeSource()
source.Update()
b = source.GetOutput()
blocks = vtk.vtkMultiBlockDataSet()
blocks.SetNumberOfBlocks(2)
blocks.SetBlock(0, a)
blocks.SetBlock(1, b)
copy = vtk.vtkMultiBlockDataSet()
copy.ShallowCopy(blocks)
# Works prior to VTK 9.3
assert id(copy.GetBlock(0)) == id(a) # Should have same ID since ShallowCopy
assert id(copy.GetBlock(1)) == id(b) # Should have same ID since ShallowCopy
It means the previous implementation was faulty
Then why isn't the previous implementation corrected to use the new correct implementation?
Thanks for the quick follow-up! Should ShallowCopy()
be overridden for vtkMultiBlockDataSet
to use CompositeShallowCopy()
? This seems like a breaking change without an issued warning/error.
The following works before VTK 9.3 and is now broken.
This is an issue for PyVista's wrapping of vtkMultiBlockDataSet
and is causing testing failures in https://github.com/pyvista/pyvista/pull/4688
import vtk
source = vtk.vtkSphereSource()
source.Update()
a = source.GetOutput()
source = vtk.vtkConeSource()
source.Update()
b = source.GetOutput()
blocks = vtk.vtkMultiBlockDataSet()
blocks.SetNumberOfBlocks(2)
blocks.SetBlock(0, a)
blocks.SetBlock(1, b)
copy = vtk.vtkMultiBlockDataSet()
copy.ShallowCopy(blocks)
# Works prior to VTK 9.3
assert id(copy.GetBlock(0)) == id(a) # Should have same ID since ShallowCopy
assert id(copy.GetBlock(1)) == id(b) # Should have same ID since ShallowCopy
The current python tests for the Web module are insufficient (reference #18767)
We need to add tests that at a minimum imports each submodule and validate how the API is being used by trame
I am happy to be assigned this task
This code has since migrated to trame-vtk and this is no longer relevant
@ben.boeckel, I'm curious if there has been any progress on shipping aarch64 wheels for the use case of running in Docker on Mac?
See also https://discourse.vtk.org/t/using-vtk-from-within-a-docker-container-on-os-x-intel-arm/9375