COMP: Fail early when wrapped Python is older than the 3.11 minimum#6659
Conversation
github-actions
Bot
added
type:Compiler
|
Using this branch, doing an incremental configure succeeds: |
dzenanz
left a comment
dzenanz
left a comment
There was a problem hiding this comment.
The code looks good. Let me try a clean build.
|
Doing a configure using CMake-GUI, then turning on |
|
When |
a08929e to
0f1a9ae
Compare
|
Good catch, @dzenanz — thanks for testing the incremental case. Fixed and pushed. The original check ran after Reproduced your scenario locally: a complete Python 3.10 wrapping configure, then an incremental reconfigure on this branch. Before, the incremental completed; now it aborts at configure: Clean and incremental configures with Python 3.11 still succeed. Your |
An explicit Python3_EXECUTABLE narrows PYTHON_VERSION_MIN/MAX to that interpreter's exact version, so find_package(Python3 3.11...) no longer rejects a below-floor interpreter. Wrapping then configures, builds, and tests for hours before every wrapped test fails at "import itk" because itk/support/types.py imports PEP 673 typing.Self, which requires Python 3.11. Check the interpreter version against the 3.11 floor in three places so no configure path slips through: - From the execute_process result inside the explicit-executable block, which re-runs every configure, so an incremental reconfigure of a cached below-floor tree also aborts. - After the first find_package, treating an empty Python3_VERSION as a failure. Otherwise the second find_package runs unversioned and silently accepts a below-floor interpreter (e.g. auto-detected system Python 3.10 after the 3.11 range rejects it).
0f1a9ae to
56cdfa7
Compare
|
Your second case (GUI: configure, then turn on Root cause: with no explicit The guard now fails on an empty if(NOT Python3_VERSION OR Python3_VERSION VERSION_LESS ${ITK_WRAP_PYTHON_MINIMUM_VERSION})
message(FATAL_ERROR "… requires Python >= 3.11, but no such interpreter was found in range …")
endif()There are now three checkpoints covering the paths you found: the Verified locally:
Your #3 (conda 3.13, missing NumPy) is already correct behavior — 3.13 passes the version floor and it fails on the NumPy component, as intended. |
|
There is something wrong with this. If I do CMake-GUI configure, then turn on wrapping, then specify |
|
@dzenanz FYI: I have other obligations tonight and tomorrow. I don't know if I'll get around to this again for a few days. This "fail quick" is getting to be a bigger scope than I can tackle today. |
|
I am not in a hurry. I will try to switch the nightly to 3.13 today. |
|
This patch is overly restrictive: |
|
Hmh, even |
|
How to point to non-system Python installed via DeadSnakes PPA ( |
|
Or even the one installed by MiniConda: |
A Python interpreter without numpy fails the required-component check with a wall of Python3_*_FOUND variables that never states which component is missing or how to supply it. Lead the error with the missing component list and the command that installs it. Behavior is unchanged; only the diagnostic text differs.
|
@dzenanz — heads-up before you finish switching the nightly: the failures you hit at 3.12 and 3.13 are numpy missing for that interpreter, not the version guard. I've pushed one more commit here that makes this obvious at configure time instead of making you read the variable dump. Evidence: the failure tracks numpy, not the Python versionUbuntu 24.04, cmake 3.28.3,
All three interpreters clear the 3.11 floor, so the new guard never fires in any of those rows. The only variable that changes the outcome is whether numpy is importable — which matches your own observation that Same venv, same CMake code, only Where the requirement comes from: Answers to your DeadSnakes / MiniConda questions
For the nightly, whichever interpreter you settle on needs both. What the new commit changesBehavior is unchanged; only the diagnostic differs. Previously: Now: The interpreter path is interpolated so the command is copy-pasteable. A missing Verified on macOS and Ubuntu 24.04 across python3.10 / 3.11 / 3.12 / 3.13, with and without numpy: every outcome matches this PR's previous head except the message text. Sorry for the runaround on the earlier rounds — your GUI and incremental-reconfigure cases were real holes and the fixes for them stand. This last one was pre-existing and I sent you chasing it. |
dzenanz
left a comment
dzenanz
left a comment
There was a problem hiding this comment.
New commit looks reasonable. I will try this when I get back to the office.
|
I didn't have luck with deadsnakes Python: This command works properly for the system-bundled Python (3.10). So I ended up using the one from Miniconda. I updated my nightly build script. |
|
Thank you for the fix, Hans! |
0ae23ea
into
InsightSoftwareConsortium:main
2 participants
Abort configuration when
ITK_WRAP_PYTHON=ONand the resolved Python is older than the 3.11 minimum raised in #6490, instead of failing atimport itkafter a full build + test cycle.A second commit names the missing Python3 component and the command that installs it, so a numpy-less interpreter reports
Missing required Python3 COMPONENT(s): NumPyplus a copy-pasteablepip installline instead of a wall ofPython3_*_FOUNDvariables.@dzenanz — this targets your
Ubuntu-22.04-gcc11.4-Rel-Pythonnightly (RogueResearch/Kitware dashboard), which currently submits with Python 3.10 and produces ~194import itkfailures every night. That dashboard's submission needs its interpreter updated to Python ≥ 3.11 (orITK_WRAP_PYTHON=OFF). Once this merges, that config will fail fast at configure with an actionable message rather than after ~3 hours of building and testing.Why the 3.11 floor is currently bypassed
CMake/ITKSetPython3Vars.cmakesetsPYTHON_VERSION_MIN 3.11, but when a dashboard passes an explicitPython3_EXECUTABLE, this block narrows the range to that interpreter's exact version:So
find_package(Python3 3.11...3.999)never rejects the older interpreter. Wrapping configures and builds normally, then every wrapped test fails identically at runtime:typing.Self(PEP 673) is Python 3.11+, consistent with #6490 raising the wrapped-Python minimum to 3.11.Fix and local verification
Adds a canonical
ITK_WRAP_PYTHON_MINIMUM_VERSIONfloor and asserts the resolvedPython3_VERSIONagainst it immediately afterfind_package, before any wrapping/SWIG work.Verified locally against
upstream/main:-DITK_WRAP_PYTHON=ON -DPython3_EXECUTABLE=python3.10→ configure aborts (exit 1) after ~75 lines withITK Python wrapping (ITK_WRAP_PYTHON=ON) requires Python >= 3.11 …, before SWIG/wrapping.-DITK_WRAP_PYTHON=ON -DPython3_EXECUTABLE=python3.11→ guard silent, full configure succeeds (exit 0),ITK_WRAP_PYTHON_VERSION=3.11.15.pre-commit run --all-files: clean.Second commit: name the missing component and its remedy
BUILD_TESTINGappendsNumPyto the hard-required component list, so an interpreter without numpy aborts configure. The previous error never stated which component was missing or how to supply it. That failure is pre-existing and unrelated to the version guard —mainbehaves identically, verified below.Before:
After:
A missing
Development.Module/Development.SABIModulegets its own line pointing at the matching-devpackage. The original variable dump is retained below the summary. Behavior is unchanged; only the diagnostic text differs.Failure tracks numpy, not the Python version (Ubuntu 24.04, cmake 3.28.3,
ITK_WRAP_PYTHON=ON,BUILD_TESTING=ON):COMPONENT could not be foundCOMPONENT could not be foundMissing … NumPy+ remedyMissing … NumPy+ remedyFull ITK configures (not a harness):
-DITK_WRAP_PYTHON=ONwith a numpy-less interpreter → aborts with the new message.-DITK_WRAP_PYTHON=ONwith numpy present →Configuring done (79.4s) / Generating done, exit 0.NumPy,Development.Module, both,Development.SABIModule) exercised directly.pre-commit run --all-files: clean.