fix: bound nanobind below 3 in the MLIR setup step - #214
Conversation
The `uv pip install` in *Set up MLIR* asked for `nanobind>=2.12.0` with no upper bound. nanobind 3.0.0 was published on 2026-08-22 and now satisfies it, and CMake configuration of ktir-mlir-frontend fails before any test runs: MLIRDetectPythonEnv.cmake calls `find_package(nanobind 2.9 CONFIG REQUIRED)`, nanobind ships CMake's SameMajorVersion compatibility file whose test is `PACKAGE_FIND_VERSION_MAJOR STREQUAL CVF_VERSION_MAJOR`, and 2 does not equal 3. Nothing here can adapt to the new major version: the rejection is CMake's version rule, not a missing symbol, and it stands as long as MLIR spells its request 2.9. This is not specific to one branch. The last green run predates the release; the first run after it failed, and any push or pull request fails the same way until this lands. `<3` rather than an exact pin because MLIR accepts any compatible 2.x, and 2.12.0 is what uv.lock already resolves for ktir-mlir-frontend. The bound goes here rather than in pyproject.toml because --no-build-isolation bypasses ktir-mlir-frontend's build-system.requires, which is what the comment above this line already explains for the cmake>=4.0 pin. Signed-off-by: WarningRan <zhuoran.liu@ibm.com>
|
Cc @fabianlim @kiszk @lchu6 @nwang-ibm @lasch — this one blocks every branch, so it is worth landing ahead of anything else in the queue. |
| # DEPENDS_TARGETS, overflowing NAME_MAX (255). CMake 4.0 truncates the | ||
| # name and relies on the trailing hash. | ||
| uv pip install scikit-build-core "nanobind>=2.12.0" "cmake>=4.0" "ninja>=1.11" | ||
| # nanobind is bounded below 3: MLIRDetectPythonEnv.cmake asks |
There was a problem hiding this comment.
nit: i think this comment can be removed, its ok to just upperbound
There was a problem hiding this comment.
upperbounding stuff is a nightmare, imho (not in the next 2 weeks but in 3+ months) 😉
I'm in favor of that comment explaining why it's upperbound and to help keep an eye on the reason.
There was a problem hiding this comment.
Keeping it — @lasch asked for the opposite on this same line. What the comment is for is the condition for lifting the bound: MLIR's find_package(nanobind 2.9 CONFIG REQUIRED).
If it's the length you mind rather than its presence, I'll cut it to one sentence.
There was a problem hiding this comment.
Same worry here, which is why the reason is in there and not just the bound — MLIR's find_package(nanobind 2.9 CONFIG REQUIRED) is the thing to watch. And it's a window rather than a pin, so 2.x still flows in on its own.
@fabianlim asked for the opposite on this line, so I've left it as is.
There was a problem hiding this comment.
yes but so you know, the MLIR version is our compiler stack is frozen, so that is why Im not worried about the upperbound.
fabianlim
left a comment
fabianlim
left a comment
There was a problem hiding this comment.
left a nit on the comment
3 participants
Summary
uv pip install ... "nanobind>=2.12.0"in the Set up MLIR step has no upper bound. nanobind 3.0.0 was published on 2026-08-22, so that specifier now resolves to it, and CMake configuration ofktir-mlir-frontendfails before any test runs:Cause
MLIR asks for a major version, and nanobind's config enforces it:
MLIRDetectPythonEnv.cmakecallsfind_package(nanobind 2.9 CONFIG REQUIRED)— request major = 2.if(PACKAGE_FIND_VERSION_MAJOR STREQUAL CVF_VERSION_MAJOR). With 3.0.0 installed that is2 STREQUAL 3, soPACKAGE_VERSION_COMPATIBLEis FALSE.So this is not a missing symbol or an API change we could adapt to — CMake rejects a 3.x config on the major-version rule alone, and will keep doing so for as long as MLIR's request is spelled
2.9.Scope
This breaks every branch, not one. The last green run is 2026-08-21 17:57 UTC, which predates the release; the first run after it (2026-08-25) failed, and any push or PR fails identically until this lands.
<3rather than an exact pin: MLIR accepts any compatible 2.x, and 2.12.0 is whatuv.lockalready resolves forktir-mlir-frontend. The bound belongs here rather than inpyproject.tomlbecause--no-build-isolationbypassesktir-mlir-frontend'sbuild-system.requires, which is what the surrounding comment already explains for thecmake>=4.0pin.Test plan
CI on this PR is the test: it exercises the changed step, and both pytest legs run behind it.