Installing both C++ API and Python bindings

[jfpanisset]

I am creating a Conan recipe for OTIO for the aswf-docker project and I want to build and install both the C++ and Python APIs. I believe this means configuring with:

-DOTIO_CXX_INSTALL=ON
-DOTIO_PYTHON_INSTALL=ON

At lines 55-112 of the top level CMakeLists.txt, if OTIO_PYTHON_INSTALL is set, libopentime.so and libopentimelineio.so end up getting installed somewhere like /usr/local/lib/python3.13/site-packages/opentimelineio/

This may be surprising for C++ clients which would expect to find libopentime.so and libopentimelineio.so in /usr/local/lib/.

I can see how when building a Python wheel, it would be advantageous to package both the C++ DSOs as well as the pybind11 wrapper DSOs in the same place, but for a non-wheels build, it seems it would be preferable to have the C++ DSOs end up in /usr/local/lib and have the pybind11 wrapper DSOs link against those, either relying on rpath or LD_LIBRARY_PATH.

Should there be (or is there) a mechanism which would differentiate a build for the purposes of creating a Python wheel from a non wheel build?

[darbyjohnston]

I think you are the first to run into this, people seem to use either the C++ or Python API, but not both. It would be nice to support this use case though, so a PR that adds this feature would be welcome.

[jfpanisset]

Canonically libopentime.so and libopentimelineio.so should land in .../lib and .../lib/python3.13/site-packages/_opentime.cpython-313-x86_64-linux-gnu.so should use rpath / runpath to find them, but I don't necessarily want to mess things up for existing installs / workflows.

Possible options:

1. install DSOs in lib, set rpath / runpath for Python DSO to ../.. which should let it find its dependent DSOs
2. install DSOs in lib, add symlinks pointing to them in lib/python3.13/site-packages
3. install DSOs in lib/python3.13/site-packages, add symlinks pointing to them in lib
4. install copies in both locations

I don't know what's the best solution that would also work for Python wheels as well as on Windows.

[darbyjohnston]

I'm not a Python expert so I'm not sure what the best option is. I'll mention this issue at the next OTIO meeting to see if anyone else has thoughts on it.

[darbyjohnston]

Hi @jfpanisset, sorry for the delay; we talked about this at the OTIO meeting today and didn't have any strong opinions. I think most people at the meeting use OTIO via PyPI or with custom builds, so this might not have any effect on them. I think we would rely on your experience in this, so it seems like a good direction to go, assuming the existing Python build still works with the changes.

@meshula Just checking if you have any opinions (if you have the time)?

[meshula]

install DSOs in lib, add symlinks pointing to them in lib/python3.13/site-packages

This variant will likely be the least surprising. dso's in the expected place, symlinks let python work. Since there wouldn't be to copies, there's no pile-on confusion of whether otio C++ loaded first, or some python plugin loaded first.

I'm not sure if the wheel packager would need a tweak to package the actual dso's rather than packaging symlinks!