On 2025-08-13 23:53, Timo Röhling wrote:
Hi Drew,
* Drew Parsons <[email protected]> [2025-08-13 16:43]:
I suspect the entire fenicsx stack will need rebuilding. This
python3-nanobind-abi is not being used as a Dependency by the needing
packages. Is there a way to get it declared?
Dependencies on the numpy abi are generated by dh_numpy3, activated by
dh-sequence-numpy3. Should we create a dh_nanobind tool (with
dh-sequence-nanobind) for the client packages to use? That would help
streamline these nanobind transitions.
I added a .pydist file which is installed as
/usr/share/python3/dist/python3-nanobind and injects the correct
dependencies; python3-cffi does it the same way. For some reason, this
does not seem to get picked up by fenics-dolfinx, though. I'm not sure
if this is an error on my part or if there is a bug in the (quite
complex) d/rules of fenics-dolfinx.
I don't know the .pydist mechanism deeply, but reading the dh_python3
man page, I see it's operating through the Python Requires-Dist
declarations, the same one that dh_python3 uses to identify normal
python package dependencies.
For python3-dolfinx-real and python3-dolfinx-complex we added the
dependency manually, handling ${nanobind:Upstream-Version} ourselves.
But we didn't (yet) do that for python3-basix, or python3-dolfinx-mpc or
python3-scifem.
I think the difference with nanobind is that these client packages only
need nanobind at build time, not a runtime. Their build uses nanobind
to generate the python extension library, but after that the symbols are
already in the library and the package doesn't need python3-nanobind
when being used.
In that sense, the .pydist is right for packages that do use nanobind at
runtime,
but doesn't directly help packages that use it only for building python
extensions.
It seems like we might want the tools to generate a "Built-Using" entry.
Drew
