Nanobind migration POC

[soswow]

Draft PR where I am exploring migration from pybind11 to nanobind.

New env flag introduced OIIO_PYTHON_BINDINGS_BACKEND = pybind11 or nanobind or both

Select which Python binding backend(s) to configure. both keeps the existing pybind11 module and also builds the experimental nanobind module.

When it is nanobine one is build it is in PyOpenImageIONanobindExperimental target.

cmake --fresh -S . -B build \
  -DUSE_CCACHE=OFF \
  -Dfmt_DIR=/opt/homebrew/lib/cmake/fmt \
  -DOpenColorIO_DIR=/opt/homebrew/lib/cmake/OpenColorIO \
  -DOIIO_INTERNALIZE_FMT=ON \
  -DOIIO_PYTHON_BINDINGS_BACKEND=both

Checklist:

• I have read the guidelines on contributions and code review procedures.
• I have updated the documentation if my PR adds features or changes
  behavior.
• I am sure that this PR's changes are tested somewhere in the
  testsuite.
• I have run and passed the testsuite in CI before submitting the
  PR, by pushing the changes to my fork and seeing that the automated CI
  passed there. (Exceptions: If most tests pass and you can't figure out why
  the remaining ones fail, it's ok to submit the PR and ask for help. Or if
  any failures seem entirely unrelated to your change; sometimes things break
  on the GitHub runners.)
• My code follows the prevailing code style of this project and I
  fixed any problems reported by the clang-format CI test.
• If I added or modified a public C++ API call, I have also amended the
  corresponding Python bindings. If altering ImageBufAlgo functions, I also
  exposed the new functionality as oiiotool options.

[lgritz]

@soswow This is looking good!

The only real concern I have at this stage is that rather than the logic for running the nanobind tests living in runtest.py, I would much rather that it all be in testing.cmake.

You can see (circa testing.cmake:197) how for each of the texture tests, it actually adds them to the list a second time with different arguments to make the same test run again with in batch texturing mode (and modifying the name to append ".batch" to make it look like a separate test). I think this is how it should work for pybind11 vs nanobind as well. There should be minimal logic changes necessary in runtest.py.

[lgritz]

@soswow Ping. I proposed some changes to the testing strategy, but otherwise would like to merge what you have as a great first step to the nanobind transition.

[jessey-git]

We try not to use this macro any longer. Just do a using namespace OIIO; here and in the other files.

[jessey-git]

The __getitem__ calls in the old pybind11 use return_value_policy::reference_internal. Do we have to do something equivalent here in some form?

[jessey-git]

The old pybind11 has a few other functions right before this and right after serialize. Seems like the following 4 were somehow missed?

        .def("to_xml",
             [](const ImageSpec& spec) { return PY_STR(spec.to_xml()); })
        .def("from_xml", &ImageSpec::from_xml)
        .def(
            "valid_tile_range",
            [](ImageSpec& self, int xbegin, int xend, int ybegin, int yend,
               int zbegin, int zend) {
                return self.valid_tile_range(xbegin, xend, ybegin, yend, zbegin,
                                             zend);
            },
            "xbegin"_a, "xend"_a, "ybegin"_a, "yend"_a, "zbegin"_a = 0,
            "zend"_a = 1)
        .def("copy_dimensions", &ImageSpec::copy_dimensions, "other"_a)