wrapping vtk filters outside source

I implemented my own c++ filters but I would like to wrap them the same way vtk does in python. I saw this nabble post.

Unfortunately, I think it’s a little out of date. The macro vtk_wrap_python3 doesn’t seem to exist anymore. Has it been replaced by something else? Is there an example, I can check out?

Yes, it has changed up quite a bit. The CMake API now requires the rest of the VTK module system to provide the information that the wrappers require. Please see this file for using the module system. Once you have modules, you can wrap them using these APIs.

There’s also a bare-bones example project called “Wrapping” that comes with the VTK source code. To use this example, copy it somewhere outside of the VTK source tree and then build it with CMake.

Thank you @dgobbi and @ben.boeckel, I will check those out.

Hi @ben.boeckel and @dgobbi , I examined the cmake function and managed to compile the example mentioned by David.
I didn’t find/understand how does vtk wrapping install itself into the python environment or package into a whl file. When I compile the example, in my case it creates a pyd file in {cmake_binary_dir}\site-packages\wrapping. I notice that path is somewhat hardcoded. Does the cmake function offered in vtkModuleWrapPython also take care of the installation? Or do I have to write a setup.py as well?

The issue I encountered was that setuptools looks for a pyd in`‘build\lib.{platform}-{python_version}’. But I couldn’t figure out how to change the path where the wrapping builds to or the directory where setuptools searches for the pyd.

I’ll try to answer your questions as best as I can. The package name for the module can be changed by editing the CMakeLists.txt file here:

  PYTHON_PACKAGE  "wrapping"

During the build the package always goes in {cmake_binary_dir}/site-packages/, and the expectation is that the install will copy it to where it belongs. I don’t have answers to your questions about setup.py or whl building, unfortunately.

Wait a minute, I wasn’t reading things properly. I would expect that, during the build, the package would go into {cmake_binary_dir}/lib/python-x.y/site-packages/ but the lib/python-x.y part is specific to linux/mac and might be different on Windows.

It handles installation, but the “default” is for Unix-style installation layouts. Wheels are not compatible with them, so they need other support. If you want to see what VTK does, you can look at CMake/vtkWheel*.cmake files in the VTK source tree. Note that such a build is only really useful for then packaging into a wheel not for use as an SDK or anything like that.

Packaging up into a wheel is not easy. VTK basically does a completely different build layout to make wheels work (because the state of Python packaging is…not great for projects with any non-Python code involved). None of the wheel auditors or whatever will like it either since you’ll need to ship all of the VTK libraries to make it happy (and delocate just doesn’t work with @loader_path, so you need to setup rpaths manually). @jcfr has ideas on how VTK-using wheels can be done, but it all sounds very hacky and “if it works, great; if not, go ask for better Python packaging support of non-Python code” to me.

In nutshell, here is the plan that would enable https://discourse.vtk.org/t/rfc-toward-supporting-distribution-of-vtk-based-modules-on-pypi/4873:

  • Leverage prior work of @dgobbi to support building VTK filters either within VTK or externally (some preliminary work here).
    • At first, we would have a CMake module in a standalone repo that could be integrated in project aiming at being built as VTK remote module or python wheels (the integration would be done like we do for this module)
  • Update VTK CI configuration to have VTK SDK published daily (e.g as GitHub release)
    • This would enable to easily setup CI using GitHub action
  • Update LookingGlassVTKModule project to leverage scikit-build
  • Publish a template similar to ITKPythonPackage but for VTK projects.

@marcwang Let us know if you specific requirements or if you would have resources to support this effort. If needed, my email is jcfr [at] kitware [dot] com

cc: @thewtex

Hi @jcfr , thanks for the links. I will check them out and see what I can do on my end. My original goal was to shift some of the vtk code inside a pure python GUI app I wrote to cpp.

I have previously attempted wrapping my own vtk based module using pybind11 without much success (stackoverflow link). Although, in that post, another person successfully pulled that off but I wasn’t able to replicate his solution at the time. The solution has been integrated into SMTK. Granted in that case, the goal was casting vtk cpp object to it’s python equivalent. Therefore, all that was needed was a type caster in pybind11.