Skip to content

Try nanobind 3 split mode - #92

Open
jdumas wants to merge 8 commits into
mainfrom
jdumas/nanobind-split-mode
Open

Try nanobind 3 split mode#92
jdumas wants to merge 8 commits into
mainfrom
jdumas/nanobind-split-mode

Conversation

@jdumas

@jdumas jdumas commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

Description

Adopt nanobind 3.0.0's new split mode:

  • build lagrange_python with BACKEND_MODULE nanobind_backend
  • require nanobind-backend>=1.0 at build time and runtime, following the final split-mode compatibility contract
  • emit a single cp310-abi3 wheel per platform
  • restrict cibuildwheel to the cp310-* build selector
  • test each completed platform wheel in isolated Python 3.10–3.14 environments before artifact upload
  • update custom type casters and limited-API-incompatible calls for nanobind 3

References:

Related Issue

N/A — this is an experimental PR to exercise nanobind 3 split mode and its wheel CI.

Motivation and Context

Split mode separates nanobind's stable-ABI frontend from its version-specific backend. This should reduce Lagrange's wheel matrix to one wheel per platform while retaining a version-specific nanobind backend.

How Has This Been Tested?

  • Built a wheel locally with uv build --wheel; it was tagged cp310-abi3 and contained lagrange/lagrange.abi3.so.
  • Installed and imported that same wheel on Python 3.10 and Python 3.14 using nanobind-backend==1.0.0.
  • Ran the Python test suite on Python 3.14: 479 passed, 4 skipped.
  • In CI, installed each exact Linux, macOS x86-64, macOS arm64, and Windows wheel in isolated Python 3.10, 3.11, 3.12, 3.13, and 3.14 environments before artifact upload. All 20 wheel/interpreter combinations passed: 479 passed, 4 skipped each.
  • Ran actionlint on .github/workflows/wheel.yaml.
  • Ran clang-format --dry-run --Werror on the changed C++ files.
  • Ran git diff --check.

Screenshots (if appropriate):

N/A

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • I have signed the Adobe Open Source CLA.
  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant