Source builds fail with nanobind 3.0.0: build requirement is unbounded but find_package asks for 2.4.0

[tdudgeon]

Since nanobind 3.0.0 was released (2026-08-22), gemmi cannot be built from source. Binary wheels are unaffected, so this only shows up for people who build: --no-binary, platforms without a wheel, git installs, and distro packagers.

Cause

pyproject.toml has no upper bound, so pip puts the newest nanobind in the PEP 517 build environment:

requires = ["scikit-build-core", "nanobind >=2.4", ...]

but CMakeLists.txt:475 asks for 2.4.0:

find_package(nanobind 2.4.0 CONFIG REQUIRED)

nanobind generates its config with COMPATIBILITY SameMajorVersion (CMakeLists.txt:116), so a request for 2.4.0 accepts 2.x only and rejects 3.0.0.

Reproduction

python3.11 -m venv v && v/bin/pip install --no-cache-dir --no-binary gemmi gemmi==0.7.5

CMake Error at CMakeLists.txt:473 (find_package):
  Could not find a configuration file for package "nanobind" that is
  compatible with requested version "2.4.0".

  The following configuration files were considered but not accepted:

    /tmp/pip-build-env-iaftk4wo/overlay/lib/python3.11/site-packages/nanobind/cmake/nanobind-config.cmake, version: 3.0.0

-- Configuring incomplete, errors occurred!
ERROR: Failed building wheel for gemmi

Reproduced on Linux/CPython 3.11 with pip 26.2.1, against both v0.7.5 and current master. Both carry the same nanobind >=2.4 / find_package(nanobind 2.4.0) pair.

Note for anyone hitting this

PIP_CONSTRAINT is the obvious workaround and it does not work — pip does not apply constraints to the PEP 517 build overlay (checked with pip 26.2.1; nanobind 3.0.0 still landed there). What does work is installing the build dependencies into the environment and disabling build isolation:

pip install scikit-build-core "nanobind>=2.4,<3" cmake ninja
pip install --no-build-isolation gemmi==0.7.5

Possible fixes

Adding the upper bound to build-system.requires would make the two agree and unbreak source builds immediately:

"nanobind >=2.4,<3",

Supporting nanobind 3.x is the larger question and presumably yours to judge — if you go that way, the find_package call would want a version range (find_package(nanobind 2.4.0...<4 CONFIG REQUIRED)) so both majors are accepted.

Happy to open a PR for the upper bound if that is the direction you prefer.

---

Filed with the help of Claude Code.