Add support for packaging VTK SDK as a wheel

[AlexyPellegrini]

This is the first batch of code to build the sdk wheel!

The URL of the SDK is composed from the target information, and no hash is checked for now, it was easier to test since my python versions mismatch between windows and linux :)

I removed the c++ code from the repo too.

I'm not sure how we are supposed to propagate the version using the dynamic metadata, for now it seems to always be v0.1.

Also I see that on "cmake-python-distributions" there is a script to update the version in different files, is this something that should be done for this repo too?

[jcfr]

we are supposed to propagate the version using the dynamic metadata, for now it seems to always be v0.1

There are two aspects to consider:

• The version of the SDK to download will be hardcoded in the CMakeLists.txt
• The version version associated with the wheel will be "dynamically" set based on the git tag

[AlexyPellegrini]

Hmm it seems that pylint triggers on VTK files, should we disable it since we won't have any python code?

[AlexyPellegrini]

we are supposed to propagate the version using the dynamic metadata, for now it seems to always be v0.1

There are two aspects to consider:

• The version of the SDK to download will be hardcoded in the CMakeLists.txt
• The version version associated with the wheel will be "dynamically" set based on the git tag

Ok, so we will tag later I guess. For now the version I hardcoded is 9.2.5. If we hardcode the version maybe I can bring back the hashes of the archives. Can we use the python 3.8 archive version for any newerpython version, or should each version match exactly ?

[jcfr]

a script [...] to update the version in different files, is this something that should be done for this repo too?

Definitely, we should look into adding a script called update_vtk_sdk_version.py that would be similar to update_cmake_version.py and also have a logic similar to the following:

vtk_version = "9.3.0"

for py_abi_tag in ["cp38-cp38", "cp39-cp39", "cp310-cp310", "cp311-cp311", "cp312-cp312"]:
    for platform_tag in ["macosx_10_10_x86_64", "macosx_11_0_arm64", "manylinux_2_17_x86_64.manylinux2014_x86_64", "win_amd64"]:
        url = f"https://vtk.org/files/wheel-sdks/vtk-wheel-sdk-{vtk_version}-{py_abi_tag}-{platform_tag}.tar.xz"

        # Download files
        # -> Adapt from https://github.com/girder/slicer_package_manager/blob/342b48d7b6fdf407731513c30f5dc147eca30d5b/tests/__init__.py#L324-L334

        # Compute checksum 
        # -> See "computeFileChecksum" at https://github.com/girder/slicer_package_manager/blob/342b48d7b6fdf407731513c30f5dc147eca30d5b/tests/__init__.py#L232-L254

[jcfr]

Hmm it seems that pylint triggers on VTK files, should we disable it since we won't have any python code?

I ended up addressing the "root" cause by installing the content of the archive in a dedicated directory without relying on the automatic discovery of wheel packages.

[codecov]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️

[AlexyPellegrini]

Thank you for making the required changes!

It seems that the mac runners fail because the platform tag (macosx_12_0...) is not the same as the one on the sdk repo. We probably need to the same thing as we do for linux.
There is an additional "cpN" in the windows url, I think that's because on WIndows the Python SOABI already contains "cpN" at the beginning.

I'm working on the script to generate the cmake urls file so we will get rid of the problem by changing the logic I think (since the URLs will be hardcoded)

[jcfr]

Before moving forward with the integration, we should add a test checking that a simple project can be built against the generated wheel.

Add files like the following:

tests/test_find_package.py
tests/packages/find_package/CMakeLists.txt
tests/packages/find_package/pyproject.toml
tests/packages/find_package/src/vtk_simple/__init__.py

Consider borrowing some of the testing logic found here:

• https://github.com/scikit-build/scikit-build-core/tree/main/tests
• https://github.com/scikit-build/scikit-build-core/blob/main/tests/conftest.py

In this simple test, the CMakeLists.txt will be similar to this:

cmake_minimum_required(VERSION 3.15...3.26)

project(
  ${SKBUILD_PROJECT_NAME}
  LANGUAGES C
  VERSION ${SKBUILD_PROJECT_VERSION})

find_package(Python COMPONENTS Interpreter Development.Module)

set(expected_version "9.2.5")
find_package(VTK ${expected_version} REQUIRED)

[AlexyPellegrini]

I'm not sure how I am supposed to fix this error:
tests/test_find_package.py:10: error: Cannot find implementation or library stub for module named "virtualenv" [import-not-found]
I tried to add virtualenv as a test dependency, but it does not seem to fix the issue.

[jcfr]

@AlexyPellegrini Can you check that the wheels¹ work as expected. Then we will merge & tag so that those are uploaded on PyPI.

cc: @finetjul

Footnotes

1. https://github.com/Kitware/vtk-sdk-python-distributions/actions/runs/18699298440#summary-53324404983 ↩

[jcfr]

Notes

Checksums:

I re-inroduced the use of checksums. This is critical to ensure integrity.

After locally downloading the wheels .. the following is helpful:

sha256sum vtk-wheel-sdk-9.5.0-cp3* | awk '{
  hash=$1; file=$2
  sub(/^.*\//, "", file)                       # strip any path
  sub(/^vtk-wheel-sdk-/, "", file)             # drop prefix
  sub(/\.tar\.xz$/, "", file)                  # drop suffix
  n=split(file, a, "-"); py=a[2]               # cp tag (e.g., cp38, cp39)
  if (NR>1 && py!=lastpy) print ""             # blank line between cp groups
  lastpy=py
  printf "set(sha256_%s\n    \"%s\")\n", file, hash
}'

CI & Runners:

• Updated check-cibw to include all platforms
• Switched to macos15-intel for x86_64, and macos-14 for arm64
• Excluded Windows 32-bit builds

[Copilot]

Pull Request Overview

This PR adds support for packaging the VTK SDK as a Python wheel by downloading pre-built VTK SDK archives, extracting them, and installing their contents along with CMake configuration files. The implementation removes the previous C++ example code and introduces new infrastructure for distributing VTK SDKs as first-class Python wheels with scikit-build-core integration.

Key changes:

• Replaces C++ example code with VTK SDK packaging infrastructure
• Adds CMake logic to download and install VTK SDK archives based on platform/Python version
• Updates minimum Python version from 3.8 to 3.10 and adds Python 3.13 support
• Introduces comprehensive testing using virtual environments to verify find_package(VTK) functionality

Reviewed Changes

Copilot reviewed 17 out of 18 changed files in this pull request and generated 11 comments.

Show a summary per file

File	Description
CMakeLists.txt	Implements VTK SDK download/extraction logic and CMake configuration file installation
cmake/vtk-sdk-urls.cmake	Defines platform-specific URLs and SHA256 checksums for VTK SDK archives
cmake/vtk-config.cmake.in	Template for CMake config file that redirects to extracted SDK
cmake/vtk-config-version.cmake.in	Template for CMake version config file
src/vtk_sdk/cmake/init.py	Entry point module for scikit-build-core cmake.prefix
src/vtk_sdk/init.py	Updated module description from cmake-module to cmake.prefix
tests/test_find_package.py	New test infrastructure for verifying VTK SDK can be found via CMake
tests/packages/find_package/*	Test package that uses find_package(VTK) to validate SDK integration
pyproject.toml	Updates Python version requirements, entry points, and test dependencies
.github/workflows/ci.yml	Updates CI to test Python 3.10-3.13 and adds wheel building checks
.github/workflows/cd.yml	Adds SDist testing and distribution checks

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Thibault-Pelletier]

Hi @jcfr,

Thx for working on this!
Just to clarify the goal of this MR, is it now to push VTK SDK versions from 9.2 to 9.5.2 on PyPI and let the VTK CI take over for versions 9.5.2+?

Will this repo be retired once the changes on VTK are cleanly integrated?

[jcfr]

Indeed, once the corresponding capabilities are in upstream VTK, there would be no need to publish the vtk-sdk wheels from this project.

I was initially thinking we could publish also publish a custom scikit build backend along side the SDK but this should instead be done in a dedicated GitHub project.

Indeed, the goal being to simplify how project like the following are externally built by leveraging VTKExternalModule (a Slicer agnostic project):

https://github.com/Kitware/LookingGlassVTKModule