Package: release.debian.org
Followup-For: Bug #1111004
I dug in a little further to follow up your point about cffi.
dolfinx (python3-dolfinx-real) catches the cffi abi but not nanobind.
As you mentioned, nanobind now (>= 2.8.0-1) has the same mechanism for
dh_python to add the abi dependency that cffi uses,
that is, python3-nanobind now provides /usr/share/python3/dist/python3-nanobind
As I mentioned, the fenics packages use nanobind at build-time not
runtime. So their pyproject.toml declare
[build-system]
requires = ["nanobind>=2.0.0"]
but not
dependencies = ["nanobind"]
dolfinx does have dependencies = ["cffi"], which is why dh_python3
catches the cffi abi.
I think upstream is doing the right thing declaring nanobind in
build-system not dependencies. But for debian packaging purpose it's
convenient for us to use dh_python3, which means using pyproject.toml
dependencies.
Can debate separately if dh_python3 ought add a Build-Using mechanism
that reads [build-system], but that will be somewhat challenging to
implement. The simplest workaround for us at this point is just to
patch our fenics packages to add nanobind to pyproject.toml dependencies.
(basix adds an extra layer of confusion by providing two
pyproject.toml, toplevel and python subdir. We use the python subdir).
So, the fenics packages are ready for the nanobind transition (now 2.9.0).
We can upload the fenics patches before or after the nanobind
transition begins.
(uploading after would mean no binNMU would be needed)