nanobind support?

[wojdyr]

I've been using m.css for a pybind11 module for a few years.
Recently, I migrated this module to nanobind, which is a next-gen library from the same author as pybind11.
I wonder, are there any plans for nanobind support in m.css?
If not, any hints what could be used as a replacement?

[mosra]

Oh, support for that definitely makes sense. I was personally playing with the idea of switching to nanobind as well, unfortunately projects that depend on my library use pybind11 so I can't really. Though there's a way to make a project support both, because the API syntax isn't too different. (Which of course won't help if you wanted to get rid of pybind11 in the first place...)

(an hour passes)

So, I got curious and tried patching one of the pybind11 tests and ... it doesn't seem to be too bad: #262

Unfortunately I don't think I can find time to finish this right now or this week, but this is definitely doable. Do you have any time frame in which you'd want to see the support being done? Can't promise I'll match that, but I can try.

[wojdyr]

Great, thanks! I don't have any time frame and can easily wait a couple months.

Nanobind can natively generate pyi stub files. I was thinking, could this be used as an input for m.css?

[mosra]

Not really. It'd be one extra indirection, meaning an extra chance for bugs to appear, and as the stubs usually remove all traces of the underlying support library, it'd be no longer possible to detect that nanobind was used and apply nanobind-specific workarounds for it.

But if you have a way to restore some partial pybind11 compatibility (basically what I did in #262 for the test file) and can temporarily build against that just for doc generation, that's a way. But gemmi seems quite large, not sure if that's a manageable path forward.