Annoucement - Switch to nanobind

[jcarpent]

We are in the process of switching from Boost.Python to nanobind in Pinocchio. The overall objective is, among other objectives, to:

• reduce the size of Python modules with similar or improved performances compared to Boost.Python
• simplify Python exposition
• facilitate Python documentation
• lower technical debt (wrt no longer maintained Boost.Python library)
• simplify CI with a unique use of stable Python API

[cmastalli]

Hi @jcarpent,

Is this compatible with Boost Python? Should we consider migrating to this in Crocoddyl?

[jcarpent]

I should have mentioned that, but we will remain compatible with Boost.Python for some time, in such a way everybody can move smoothly towards Nanobind.

[jcarpent]

Hi @jcarpent,

Is this compatible with Boost Python? Should we consider migrating to this in Crocoddyl?

As discussed above, at some point it will be welcome to move to nanobinds, even if we will continue to support Boost.Python for a while.

[ManifoldFR]

With @jorisv we think we could add some Boost.Python converters to intercept and ingest nanobind-exposed types (to allow some degree of interop between the future nanobind bindings and older code which depends on Pinocchio), but there's no guarantee on how tight the integration could be and how much code could be covered with this.

We will definitely recommend rewriting your own bindings to nanobind when the time comes. It would absolutely be worth it just for the better developer experience. You will likely end up with a net smaller amount of bindings code that compiles faster and is easier to debug.

[jcarpent]

Just a small remark if the downstream project does not use the Pinocchio C++ Boost.Python API, then nanobind and Boost.Python will be able to coexist.

[cmastalli]

Thanks for the explanation!

[cmastalli]

It seems nanobind is targeted to C++17. If this is correct, it will also impose a minimal C++ standard to Pinocchio and other third-party projects.

[jcarpent]

It is just for Python bindings, so no real consequence for the main lib.

[ManifoldFR]

It seems nanobind is targeted to C++17. If this is correct, it will also impose a minimal C++ standard to Pinocchio and other third-party projects.

To add further detail: only the bindings' CMake target will require C++17 to be compiled; it will be a MODULE target which cannot be linked to.*
If the bindings' headers contain utilities which can be used for the bindings of downstream projects, they'll be added to an INTERFACE target which can be consumed by downstream bindings' own MODULE targets -- then those will require C++17 also. C++-only (no Python) workflows will not be affected.

Bumping the C++ standard for 17 for the bindings alone is not so unreasonable. GCC fully supports C++17 since version 8, and Pinocchio right now already requires C++14 when linking to Boost versions above 1.82 (C++11 for Boost<=1.81).

*This is recommended good practice for Python extension modules, as they are not supposed to be linked to. What we're doing right now in Pinocchio's bindings (creating a linkable SHARED target) is actually wrong.

[nim65s]

C++17 is the default standard of the default compiler in ubuntu LTS since 22.04 (which will be the oldest supported version in a couple months)

It is available since 18.04.

I think we should therefore stop bothering about C++ < 17 support after May 1st 2025.