Skip to content

fix: bound nanobind below 3 in the MLIR setup step #214

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
fabianlim merged 1 commit into from
Aug 25, 2026
+5 −1
Merged

fix: bound nanobind below 3 in the MLIR setup step #214

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion .github/workflows/ci.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,11 @@ jobs:
# mlir_generate_type_stubs() builds a 283-char target name by joining
# 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

@fabianlim fabianlim Aug 25, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: i think this comment can be removed, its ok to just upperbound

@lasch lasch Aug 25, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@WarningRan WarningRan Aug 25, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@WarningRan WarningRan Aug 25, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@fabianlim fabianlim Aug 25, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes but so you know, the MLIR version is our compiler stack is frozen, so that is why Im not worried about the upperbound.

# find_package for nanobind 2.9, and nanobind ships CMake's
# SameMajorVersion compatibility file, so a 3.x config is rejected on
# the major version alone. Widen only when MLIR's request changes.
uv pip install scikit-build-core "nanobind>=2.12.0,<3" "cmake>=4.0" "ninja>=1.11"
echo "CMAKE_ARGS=-DMLIR_DIR=$MLIR_DIR" >> $GITHUB_ENV

- name: Install project and dependencies
Expand Down
Loading