On 2025-08-13 23:53, Timo Röhling wrote:
Hi Drew, * Drew Parsons <dparsons@emerall.com> [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