[dzenanz]

When ITK's selected Python differs from the one a Python-wrapped VTK was built with, ITKVtkGlue now fails with an error naming both, instead of FindPython3's misleading "missing: Development.Module".

Root cause

On Windows, FindPython3 searches the registry before PATH and takes the newest version in range, so ITK's interpreter lookup can select e.g. Python 3.14. VTK's vtk-find-package-helpers.cmake then fills Python3_INCLUDE_DIR/Python3_LIBRARY with its build-time (3.12) paths but keeps the already-set 3.14 interpreter. The mixed artifacts make VTK's own find_package(Python3 ... Development.Module) fail.

find_package(VTK) is no longer REQUIRED, so the failure surfaces as VTK_Python_FOUND=0 and ITK reports the interpreter and VTK's include/library paths, pointing at Python3_EXECUTABLE. A missing VTK gets its own error.

Test results

Windows 11, VS 2026, CMake 4.4.4, configure only (ITK_BUILD_DEFAULT_MODULES=OFF, Module_ITKVtkGlue=ON, BUILD_SHARED_LIBS=ON, BUILD_TESTING=ON), VTK 9.7 wrapped with Python 3.12, Python 3.14 also installed:

Python3_EXECUTABLE	main	this PR
unset (ITK selects 3.14)	FindPython3 "missing: Development.Module"	new clear FATAL_ERROR
Python 3.12	configures	configures

AI assistance

• Tool: Claude Code
• Role: diagnosed a nightly dashboard configure failure, implemented the change, ran the configure matrix above
• All changes reviewed by the submitter

PR Checklist

• No API changes were made (or the changes have been approved)
• No major design changes were made (or the changes have been approved)
• Added test (or behavior not changed)
• Updated API documentation (or API not changed)
• Added license to new files (if any)
• Added Python wrapping to new files (if any) as described in ITK Software Guide Section 9.5
• Added ITK examples for all new major features (if any)

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable defects were established.

Summary

Finds VTK before ITK chooses Python when Module_ITKVtkGlue is explicitly enabled.

• ITK uses the Python that its wrapped VTK was built with.

dzenanz explicitly noted that indirect module enablement does not find VTK early.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[ITK needs Python] --> B{Module_ITKVtkGlue enabled explicitly?}
  B -->|Yes| C[Find VTK first]
  C --> D{VTK and its Python usable?}
  D -->|No| E[Stop with an error]
  D -->|Yes| F[Run ITK Python discovery]
  B -->|No| F
  F --> G[Resolve and build enabled modules]

Loading

_{Reviews (1) · Last reviewed commit: "COMP: Make ITK use the Python that a Pyt..." · Reviewed by Greptile}

[dzenanz]

Can we review/merge this today? I hit this problem again on my Mac.

[blowekamp]

The changes in VtkGlue look good.

I have concern that directory calling VtkGlue's its-module-init.cmake out of order may have side-effects. Additionally it's not a sustainable practice for other modules that have pre-requisites.

If you set the configuration of ITK to the matching VTK's python executable does the configuration work with out the addition of the line to the top-level cmake?

[dzenanz]

@blowekamp Good call. I dropped the top-level CMakeLists.txt change, so itk-module-init.cmake again runs only during module enablement. Including it early didn't change anything ITK reads, but it did run the file twice (the static-VTK warning would have printed twice) and loaded VTK and its dependency settings earlier than usual.

To your question: yes. With Python3_EXECUTABLE set to VTK's Python, configure works without that line, on both main and this PR. The line only mattered when Python3_EXECUTABLE was unset: ITK would then adopt VTK's Python automatically. Without it, ITK can pick a newer Python, and this PR now turns FindPython3's "missing: Development.Module" into an error naming the selected interpreter and VTK's Python include and library paths, telling the user to set Python3_EXECUTABLE.