Package: nanobind-dev
Version: 1.9.2-1
Followup-For: Bug #1067085
The path discrepancy comes from the cmake build, with CMakeLists.txt
defining installation path NB_INSTALL_DATADIR via
CMAKE_INSTALL_DATADIR (which is /usr/share).
The upstream installation instructions don't mention cmake (they
explain how to use cmake for using nanobind, not for installing it).
Instead the installation instructions recommend pip or conda install.
Looking at the pypi wheel that pip would use, it doesn't specify the
top level path at all, it just starts the files from "/nanobind". So
it would be pip itself knowing to install them to /usr/lib/python3.x.
It looks like upstream isn't expecting CMakeLists.txt to be used
directly for installation.
On the other hand, pyproject.toml does specify cmake as a build
requirement, although setup.py does not use it. I'm not aware that
pip build would invoke cmake just because it's listed in
[build-system] requires.
So it's a bit of a mystery what upstream's intentions for nanobind
installation are. It's as if they have some other unpublished script
that they use to generate pypi wheels.
The debian packaging declares a cmake build via PYBUILD_SYSTEM = cmake.
What do we get if we don't do that, and just let pybuild process
pyproject.toml and setup.py as a normal python module without calling
cmake directly? (that probably needs
Build-Depends: pybuild-plugin-pyproject)
(pyproject.toml also lists ninja. Perhaps pybuild/pip would invoke
ninja, which invokes cmake. scikit-build is also a concerned party.
But setup.py doesn't explicitly invoke any of them.
I haven't tried this direct python build yet.)
On the other hand, upstream's github CI testing does invoke cmake
explicitly, in .github/workflows/ci.yml. But is that just for tests?
(i.e. "using" nanobind, not "installing" it)
If we do move the nanobind files to /usr/lib/python3, there's
still the question of how cmake will find it there (cmake find_package
would search for an arch-independent package in /usr/share/<name>,
or /usr/share/cmake/<name>). But that's where the upstream usage
instructions come in, they recommend invoking ${python} -m nanobind --cmake_dir
and adding it to CMAKE_PREFIX_PATH. So in that sense a "python"
installation should be ok, rather than a PYBUILD_SYSTEM = cmake
installation.
That said, looking at the usage guides it seems to be that nanobind
should work just fine with cmake from /usr/share/nanobind, so long as
you ignore the recommendation to use "python3 -m nanobind --cmake_dir"
Except that NB_DIR would need to be set (used in
nanobind-config.cmake, though nanobind-config.cmake could be easily
patched to give it a default value if not already set)
Is there any use-case for using nanobind (using, not installing)
without doing it through cmake? (i.e. does the nanobind python module
have any purpose other than providing a --cmake_dir flag for defining
NB_DIR in a user's cmake scripts?)
