Feature
nanobind is a Python binding library written by same person who wrote Pybind11. gtsam should use that instead of Pybind11 for Python bindings.
Motivation
It's main advertised benefits are smaller binaries, faster builds, and faster runtime. One of the other, less advertised benefits is that it supports building binaries against the Stable ABI starting with Python 3.12. This means you can build one binary and have it work for multiple versions of Python, which means you wouldn't have to use the time consuming mega matrix to build a wheel for each version of Python and every OS.
Pitch
Modify wrap to output nanobind bindings. The API is similar to Pybind11, but there are some feature caveats; notably, multiple inheritance is unsupported, but a search through the repo indicates that's very rarely used. Then, build one wheel per OS against Python 3.12 and cut down the CI matrix to 1/4th of the size.
Alternatives
Spamming more caching, but that's hard since we really don't have the space for that because vcpkg caches take like 25% of the space.
Wait for Intel Macs to be unsupported. That's 1/4th of the matrix right there! :) We can do that as well, but there's still a bunch of wheels to build.
Optimize compile times. I'm pretty sure this is close to impossible given the sheer number of templates instantiated and the deep header dependencies that are almost impossible to disentangle. I tried to clean up includes once, but that made no discernible difference, unsurprisingly. I still have the branch if you're interested (it's a small +13, -21 diff.)
Wait for C++ modules? But that's like, 5-7 years out and you'd want to be on C++23 for import std;. That's a long time...
Additional context
As far as I can tell, the major downsides to nanobind are the lack of multiple inheritance and changes to object ownership, but I think both aren't issues for this project.
Feature
nanobind is a Python binding library written by same person who wrote Pybind11. gtsam should use that instead of Pybind11 for Python bindings.
Motivation
It's main advertised benefits are smaller binaries, faster builds, and faster runtime. One of the other, less advertised benefits is that it supports building binaries against the Stable ABI starting with Python 3.12. This means you can build one binary and have it work for multiple versions of Python, which means you wouldn't have to use the time consuming mega matrix to build a wheel for each version of Python and every OS.
Pitch
Modify
wrapto output nanobind bindings. The API is similar to Pybind11, but there are some feature caveats; notably, multiple inheritance is unsupported, but a search through the repo indicates that's very rarely used. Then, build one wheel per OS against Python 3.12 and cut down the CI matrix to 1/4th of the size.Alternatives
Spamming more caching, but that's hard since we really don't have the space for that because vcpkg caches take like 25% of the space.
Wait for Intel Macs to be unsupported. That's 1/4th of the matrix right there! :) We can do that as well, but there's still a bunch of wheels to build.
Optimize compile times. I'm pretty sure this is close to impossible given the sheer number of templates instantiated and the deep header dependencies that are almost impossible to disentangle. I tried to clean up includes once, but that made no discernible difference, unsurprisingly. I still have the branch if you're interested (it's a small +13, -21 diff.)
Wait for C++ modules? But that's like, 5-7 years out and you'd want to be on C++23 for
import std;. That's a long time...Additional context
As far as I can tell, the major downsides to nanobind are the lack of multiple inheritance and changes to object ownership, but I think both aren't issues for this project.