Incorrect module name in a stable ABI wheel?

[stumpylog]

I'm transitioning a project to use nanobind, and am seeing an oddity when building via cibuildwheel. I get a wheel like: "exifmwg-0.2.0-cp312-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64", but the compiled .so seems to be specific to Python 3.12: bindings.cpython-312-x86_64-linux-gnu.so

I've configured the stable ABI as such:

  nanobind_add_module(
    bindings
    NB_STATIC
    NB_SUPPRESS_WARNINGS
    STABLE_ABI
    LTO
    src/exifmwg/bindings.cpp
    ${CORE_SOURCES})

as well as

[tool.scikit-build]
build-dir = "build/{wheel_tag}"
wheel.py-api = "cp312"
wheel.packages = [ "src/exifmwg" ]

Maybe related to #1047

[wjakob]

Can you reproduce this outside of cibuildwheel?

[stumpylog]

Yes. Building with just uv build --wheel, after clearing dist and build folders, I get bindings.cpython-312-x86_64-linux-gnu.so inside a wheel named exifmwg-0.3.0-cp312-abi3-linux_x86_64.whl

nanobind == 2.7.0
scikit-build-core==0.11.4

[stumpylog]

The branch/repo, in case that helps: https://github.com/stumpylog/exifmwg/blob/feature/single-class/CMakeLists.txt

It has for the moment removed the sable ABI configuration

[thomthom]

I'm also seeing in my nanobind migration that the wheel get named with abi3 suffix, but the binaries doesn't (and won't load in any python versions other than the one that built it).

Using uv + scikit-build-core + nanobind for my project. I see this on Windows and Linux builds (not building cibuildwheel`

I'm wondering if something is passed in from the build system that cause the suffix or ABI config to not be set as expected... 🤔

nanobind/cmake/nanobind-config.cmake

Lines 16 to 47 in dbe8a3c

	# Check if FindPython/scikit-build-core defined a SOABI/SOSABI variable
	if(DEFINED SKBUILD_SOABI)
	set(NB_SOABI "${SKBUILD_SOABI}")
	elseif(DEFINED Python_SOABI)
	set(NB_SOABI "${Python_SOABI}")
	endif()
	if(DEFINED SKBUILD_SOSABI)
	set(NB_SOSABI "${SKBUILD_SOSABI}")
	elseif(DEFINED Python_SOSABI)
	set(NB_SOSABI "${Python_SOSABI}")
	endif()
	# Error if scikit-build-core is trying to build Stable ABI < 3.12 wheels
	if(DEFINED SKBUILD_SABI_VERSION AND SKBUILD_ABI_VERSION AND SKBUILD_SABI_VERSION VERSION_LESS "3.12")
	message(FATAL_ERROR "You must set tool.scikit-build.wheel.py-api to 'cp312' or later when "
	"using scikit-build-core with nanobind, '${SKBUILD_SABI_VERSION}' is too old.")
	endif()
	# PyPy sets an invalid SOABI (platform missing), causing older FindPythons to
	# report an incorrect value. Only use it if it looks correct (X-X-X form).
	if(DEFINED NB_SOABI AND "${NB_SOABI}" MATCHES ".+-.+-.+")
	set(NB_SUFFIX ".${NB_SOABI}${NB_SUFFIX_EXT}")
	endif()
	if(DEFINED NB_SOSABI)
	if(NB_SOSABI STREQUAL "")
	set(NB_SUFFIX_S "${NB_SUFFIX_EXT}")
	else()
	set(NB_SUFFIX_S ".${NB_SOSABI}${NB_SUFFIX_EXT}")
	endif()
	endif()

Local build produce fastgpx.cp312-win_amd64.pyd - should there not be an abi3 in there?

[thomthom]

I'm seeing that the nanobind library generated is named nanobind-static - should it not be nanobind-static-abi3 given this setup:

nanobind_add_module(
  # Name of the extension:
  fastgpx
  # _fastgpx_impl

  NB_STATIC

  # Marks the nanobind include directories as SYSTEM to suppress warnings.
  NB_SUPPRESS_WARNINGS

  # Target the stable ABI for Python 3.12+, which reduces
  # the number of binary wheels that must be built. This
  # does nothing on older Python versions.
  STABLE_ABI

  # Sources:
  python_fastgpx.cpp
  python_utc_chrono_nanobind.hpp
)

[thomthom]

I just realised that I was missing Development.SABIModule.

Maybe that should emit a warning when STABLE_ABI is set instead of silently resetting it?

nanobind/cmake/nanobind-config.cmake

Lines 353 to 358 in dbe8a3c

	# Stable ABI builds require CPython >= 3.12 and Python::SABIModule
	if ((Python_VERSION VERSION_LESS 3.12) OR
	(NOT Python_INTERPRETER_ID STREQUAL "Python") OR
	(NOT TARGET Python::SABIModule))
	set(ARG_STABLE_ABI FALSE)
	endif()

[NAThompson]

I also got hit by this-I wonder if it is possible to make requesting the stable ABI without Python::SABIModule a hard error, or perhaps make requesting the stable ABI add Python::SABIModule?

[wjakob]

Could I ask you to make a PR for this?

Note that we've so far had the policy to ignore the STABLE_ABI flag on Python < 3.12. So the modified CMake script should not blindly error out when Python::SABIModule is not available, it depends on the Python version..

[NAThompson]

@wjakob : Attached is a patchfile which implements (what I hope) is the desired behavior:

• Continue to ignore the STABLE_ABI flag for python < 3.12.
• Add Development.SABIModule whenever python >= 3.12 and it hasn't already been already been added.
• Hard error if Python::SABIModule cannot be found and STABLE_ABI requested on python ≥ 3.12.
• Removed Development.SABIModule from the docs and let it become an implementation detail.
• Removed Development.SABIModule from the root CMakeLists.txt so that this codepath is exercised in the unit tests.
• Updated the CI so include Python 3.12, 3.13, and 3.14 into the build matrix.

Behavior sensible?

auto_sabi.patch

[hpkfft]

This patch does not apply to the latest release, v2.10.2, nor to the latest development branch in git.
(Python 3.8 is no longer supported.)

My personal preference would be to leave OPTIONAL_COMPONENTS Development.SABIModule in the top-level CMakeLists.txt
rather than adding code to find it automatically. In other words, go with the following:

make requesting the stable ABI without Python::SABIModule a hard error

The error message in this patch

+          "nanobind_add_module(${name} STABLE_ABI ...) requires the Python::SABIModule "
+          "target, but it could not be found. Ensure that 'Development.SABIModule' is "
+          "included in your find_package(Python ...) call.")

does not make sense if nanobind-config.cmake quietly finds Development.SABIModule itself.