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.

[AlexyPellegrini]

FYI, I bumped VTK to 9.5.0 and Python to 3.10+ from 3.8+ @finetjul @Thibault-Pelletier @LucasGivord

[finetjul]

LGTM

@jcfr good with you ?