RFC: Toward supporting distribution of VTK based modules on PyPI

[ben.boeckel (Ben Boeckel (Kitware))]

@lassoan

can be built against a VTK build tree and maybe even install tree

Any module which requires a build tree and doesn’t work with a build tree is either:

• using internal APIs (bad module, don’t do that); or
• a bug in VTK’s install tree

Please file bugs when this happens.

@lassoan

Requirement 2 is needed because there are several non-essential modules in VTK repository that would not be practical to include in the main VTK Python package on PyPI as they would make VTK package bloated with features that very few people need and/or would require special hardware or software configurations to be usable.

This sounds like a very good line to use for moving some code out of VTK and into its own repository (or multiple!). They’d also serve as an example of “see, here’s how to make a wheel of a VTK-using project”. Actually doing the split is likely to be a huge undertaking (and ParaView will need to support an external VTK first in any case for this to become a practical reality).

(replying to the overall effort here):

I do have issues with wheels in particular because shipping C++ APIs with wheels is a very unsolved problem that I haven’t seen anyone working on it. Conda does support non-Python code and is likely more suitable for a proper solution for this (though if wheels do end up having ways of shipping non-Python APIs reliably, we can look at that again). Things to consider:

• where do headers live within a wheel?
• where should the vtk-config.cmake and associated files go?
• VTK hierarchy files also need to go into the package

Now the new VTK build system should be able to deal with any such layout, but making it Just Work is up to conventions in the wheel-using ecosystem.