Run pre-commit autoupdate, fix stale pyproject.toml comments

[nicholasjng]

black was replaced by ruff-format, so the comments were stale.

[nicholasjng]

oioioi, looks like the bindings are incompatible with bzlmod.

[nicholasjng]

@macandy13 I saw that you pushed nanobind v1.2.0 into the Bazel registry, do I need to push other tags in order to be able to use them?

[dmah42]

thanks!

[macandy13]

Sorry for the late reply.

Building the Python bindings with bzlmod was waiting on some changes in rules_python, but I lost track of the work there as I switched projects in the meantime. IIRC the problem I faced back then was that the BUILD targets for the bindings depend on the currently installed Python version, and it was very hard to get the C++ headers of that installed Python interpreter to build in bzlmod.

So I don't think it is easy to solve this problem with just using nanobind from the bzlmod registry. My feeling back in June was that setup.py should be replaced by some Python version specific bazel targets, but that was quite a drastic change and was not compatible with the CI approach taken here, so I kept my hands off it.

Seems like it is time to revisit this. Happy to brainstorm what could be good paths forward now that bzlmod is the de-facto standard.

[nicholasjng]

Thanks for getting back to me!

I saw a related discussion by someone trying to push nanobind to vcpkg, and the answer there really resonated with me: wjakob/nanobind#341 (comment)

In short, nanobind is so simple and small, yet so configurable that it is recommended to bootstrap everywhere instead of pulling from a centralized registry such as vcpkg or in this case the BCR.

I agree very much with that assessment - build flags provided by the guy pushing the nanobind tags to the BCR might not work for everyone, and some users might want or need to configure things differently (e.g., we currently do not have stable ABI support here in GBM yet).

The second part of why I think this is the way to go is the Python version. I think rules_python is the way better approach than just sourcing the current system Python's headers like we do now, but registering a toolchain for every version might be overkill.

Then again, rules_python devs seem to make it a point to follow strict hermeticity. I'm not deep enough into the Bazel Python ecosystem, so all tips are appreciated.