Bug#1067085: nanobind-dev not in python path and without distribution info
Hi, On Mon, 18 Mar 2024 08:16:33 + Francesco Ballarin wrote: 1) The user guide at https://nanobind.readthedocs.io/en/latest/building.html#finding-nanobind states that the downstream user should query python3 -m nanobind --cmake_dir to determine where nanobind is installed. The `python3 -m nanobind --cmake_dir` call is only needed for the pip/conda package because it installs the CMake config in a location that is not searched by default. It is not necessary for the Debian package -- find_package(nanobind) works out of the box -- but does not hurt (much) either. 2) Downstream users or packages may have a pyproject.toml file which contains [build-system] requires = ["nanobind"] I added a new binary package python3-nanobind, which provides the nanobind module for this use case. Technically, it is not needed for the reason outlined above, but if it makes life easier for downstream users, that's good enough for me. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1067085: nanobind-dev not in python path and without distribution info
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/,
or /usr/share/cmake/). 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?)
Bug#1067085: nanobind-dev not in python path and without distribution info
Package: nanobind-dev Version: 1.9.2-1 Severity: normal X-Debbugs-Cc: francesco.balla...@unicatt.it, dpars...@debian.org Dear Maintainer, I would like to ask two questions related on usage of nanobind-dev from python: 1) The user guide at https://nanobind.readthedocs.io/en/latest/building.html#finding-nanobind states that the downstream user should query python3 -m nanobind --cmake_dir to determine where nanobind is installed. However, this is not currently possible with nanobind-dev, since the file __init__.py is not installed among the standard python paths. To make this work, one has to use PYTHONPATH=/usr/share python3 -m nanobind --cmake_dir 2) Downstream users or packages may have a pyproject.toml file which contains [build-system] requires = ["nanobind"] When building with --no-build-isolation, this requires the nanobind-*.dist-info folder to be present. Currently either pip3 show nanobind or PYTHONPATH=/usr/share pip3 show nanobind show WARNING: Package(s) not found: nanobind while nanobind installed from pypi.org would show something like Name: nanobind Version: 1.9.2 Summary: nanobind: tiny and efficient C++/Python bindings Home-page: https://github.com/wjakob/nanobind Author: Wenzel Jakob Author-email: wenzel.ja...@epfl.ch License: BSD Location: /usr/local/lib/python3.11/dist-packages Requires: Required-by: = The next version of fenics-dolfinx, to be packaged in Debian upon release, will require --no-build-isolation and nanobind. Thanks, Francesco -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages nanobind-dev depends on: ii libeigen3-dev 3.4.0-4 ii robin-map-dev 1.2.1-1 nanobind-dev recommends no packages. nanobind-dev suggests no packages. -- no debconf information
