Pin pybind11 version to v2.10.0 commit id to avoid unanticipated changes

[nnshah1]

Using a tag or branch in the GIT_TAG FetchContents CMake setting can introduce unwanted changes. Thus pinning to a specific commit id is recommended.

https://cmake.org/cmake/help/latest/module/ExternalProject.html#command:externalproject_add

In particular - this change (merged into the v2.10 branch of pybind11)

pybind/pybind11@8869984

changed the behavior of locale setting in the python stub process.

Alternately we can explicit configuration before initialization but in either case pinning the version of pybind is desireable.

Fixes triton-inference-server/server#5321

[rmccorm4]

Nice find! So this is pinning to a commit before the locale changes were introduced?

Alternately we can explicit configuration before initialization

Can you point to the configuration you're referring to?

[nnshah1]

Nice find! So this is pinning to a commit before the locale changes were introduced?

Alternately we can explicit configuration before initialization

Can you point to the configuration you're referring to?

I pinned to the v2.10.0 release commit id - I believe the change came in around v2.10.2 or v2.10.3. I figured that was the original intent.

For configuration, we'd have to change the constructor from the default to one that passes in a PyConfig object:

https://github.com/pybind/pybind11/blob/0e43fcc75e6b7429e3511dfb44343ec05a0ab843/include/pybind11/embed.h#L293

I think actually the bug has been fixed upstream as my guess is that the intent of the pybind initialization without arguments was to be backwards compatible. This is master:

https://github.com/pybind/pybind11/blob/0e43fcc75e6b7429e3511dfb44343ec05a0ab843/include/pybind11/embed.h#L201

Rationale described here: pybind/pybind11#4473

But this is the branch we were pulling from:

https://github.com/pybind/pybind11/blob/5b0a6fc2017fcc176545afe3e09c9f9885283242/include/pybind11/embed.h#L201

Starting from an isolated config and adding in "use environment" I believe is not quite enough. Though the environment is passed my guess is that the configure_locale option also needs to be set:

https://docs.python.org/3/c-api/init_config.html#c.PyPreConfig.configure_locale

Looks like in master they have switched to use the python config as base - which behaves closer to the python interpreter instead of the isolated mode in v2.10 branch.

I figured since we hadn't intentionally moved forward - the safest was to move back to the v2.10.0 commit id (but we can decide to upgrade / create our own config instead)

(also waiting on CI to test a build - so for now a placeholder)