Use nanobind for Stable ABI wheels

[dalcinl]

Python's Limited API/Stable ABI allows for building wheels that can run in multiple Python versions. Unfortunately, pybind11 does not support it. However, the newer and leaner C++ binding framework nanobind (from the same author as pybind11) does for Python 3.12+.

In order to support Python 3.10 and 3.11, version-specific wheels are still required. However, starting from Python 3.12 and up, a single wheel can be installed on any upcoming Python version (currently: 3.12, 3.13, 3.14).

nanobind supports Eigen, however it requires at least version 3.3.1. I went ahead and bumped the subrepo to track the head of branch 3.4, I hope this is OK.

The Python CI/CD was improved considerably. Wheels are built with 3.10 to 3.12, but tested with 3.10 to 3.18, for both Linux and macOS x86_64/arm64. The PyPI publishing infrastructure was also improved, however there are some trivial TODOs that can be done once this PR is merged and we can test publishing to the Test PyPI server.

[dalcinl]

@rdbisme I would need additional help on your side to setup trusted publishing on Test PyPI and the main PyPI indices. Alternatively, you could give me maintainer permissions temporarily and I can handle these things. Think about it, it is not urgent, we can do it after the new year.

[rdbisme]

You know what? I never liked the vendored stuff. Can we remove them altogether (and fetch them in the CI at runtime if we need them using whatever method (conan? conda?).

Like that we reduce the amount of changes in the PRs.

What do you think?

[rdbisme]

Also send me a mail and I'll add you as PyPi maintainer.

[dalcinl]

I never liked the vendored stuff. Can we remove them altogether

I'm not so sure. If you go that way, for regular C++ users of Mutation++, a git checkout will no longer be self-contained. Users will have to provide their own Eigen at the right version.

(and fetch them in the CI at runtime if we need them .

Maybe a palatable alternative would be to use CMake's FetchContent (requires CMake 3.14)
https://cmake.org/cmake/help/latest/module/FetchContent.html
That way CMake takes care of git checkout for the upstream Eigen repo, setting up the dependency for us.
I should note that I DO NOT have any experience with it, I don't know whether the switch will be straightforward.
There is a drawback, though: a Mutation++ git checkout is not self-contained, internet access would be required at CMake configure time to git clone the Eigen repository.

using whatever method (conan? conda?)

For the particular case of Eigen, a simple git clone is enough, as Eigen is a header-only library, therefore there is no need to build nor time to save by using pre-built packages like conda.

Like that we reduce the amount of changes in the PRs.

Well, I could split the PR in two, and make the Eigen update a single PR. IHMO, any changes from git subrepo updates can be ignored (as long as you trust the contributor). Of course, reviewing the PR in the GitHub Web UI becomes harder. Therefore, a PR split may be justified.

The root evil here was switching to use git subrepo for a third-party dependency. Indeed, updates become extremely verbose. The git subrepo approach is great for "absorption" a subproject into a bigger project (I've been involved in such merges and used git subrepo for it), but IMHO is a bad thing for managing third-party dependencies.

[rdbisme]

Maybe a palatable alternative would be to use CMake's FetchContent (requires CMake 3.14)

Or ExternalProject, in order to allow people to use pre_installed system dependencies instead of forcing them to rebuild a vendored version with a -DFlag. Not sure if you can with FetchContent.

I'd say to leave this MR pending and provide another one which unvendors the dependencies and fetches them at runtime using the best CMake method.

Once merged that we can go ahead with nanobind.

What do you think?