OTIO is in the process of moving the adapters that were previously bundled within the projects out of the project in seperate packages. This raises some questions, like how will users be able to discover adapters, install them, install groups of adapters, etc.
This document describe how we could automatically discover third-party OTIO plugins in order to build a central place where OTIO users can go to see the list of available plugins. Installing and everything else is out of the scope for this document.
The idea would be to have a central place where users can see the list of adapters available, see which is bundled with OTIO and which is not, etc. Doing the work to gather this list is usually a good idea because the user might not know all the ways to find adapters out there while OTIO contributors probably have a good idea of where to look for to find new adapters.
That list should proabbly be part of OTIO's documentation. This would allow the list to be source controlled and it would allow us to review any modifications made to it. Part of the list can be automatically generated and the other part can be manually managed. That's because some things are possible to discover using APIs (PyPI, GitHub, etc), while others are not (for example the list of DCCs that integration OTIO natively).
The OTIO TSC should be able to vet what goes on the list.
Finally, the automatic discovery system should be easy to maintain and shouldn't add extra maintainenance overhead (or as less as possible).
- pytest docs have a list of available plugins.
They base themselves on packages prefixed with
pytest-in PyPI to build that list. - cibuildwheel have a list of working examples. They store projects in a YAML file, and then they use a script to periodically query the projects to build the page and keep stats up to date.
Here is a list of options that could be used to compile a list of plugins automatically. Options are not mutually exclusive and could be combined to get the best results.
This is the most simple and straight forward option of all. Querying project names on PyPI is simple.
Happilly for us, our plugin template already suggests that convention. But it's only a weak convention and nothing prevents plugins creators to name their plugins using a different naming convention.
Use PyPI Trove classifiers
When creating a Python package and uploading it to https://pypi.org, it's possible to specificy Trove classifiers, like described in https://packaging.python.org/en/latest/tutorials/packaging-projects/#configuring-metadata. Classifiers are equivalent to tags. PyPI supports a predefined list of classifiers. The process to request a new classifier is to create an issue in https://github.com/pypa/trove-classifiers.
Though possible, it is usually hard to get a new classifier accepted. See pypa/trove-classifiers#89 (comment) on what criterias the PyPI admins use.
So unfortunately for us, this isn't an options.
A plugin author can also add tags to his repository (GitHub and GitLab both support tags). This covers a case where a plugin was already published to PyPI under a non "compliant" name. With repo topics, we could query GitHub and GitLab for specific tags and get the list of plugins from there.
Using PyPI's APIs, it is somewhat possible to get a package's metadata and from that get the list of registered entrypoints. (Add link). But again that doesn't work for all cases because not all plugins are published on PyPI. For example, resolve-otio isn't.
But it would be an interesting idea for plugins published on PyPI since we wouldn't have to rely on naming convention. Note that it's not "straight forward" AFAIK.
There is also the possibility of manually listing a plugin if there is no (easy) way to automatically discover it. Manual entries are important because there is some adapters that Will never be published to PyPI. One example is RV.
Other examples can be seen at https://github.com/AcademySoftwareFoundation/OpenTimelineIO/wiki/Tools-and-Projects-Using-OpenTimelineIO.
Considering the requirements and the possible options, I think we could have a schedule GitHub Action workflow that would periodically fetch different sources (PyPI, GitHub etc) and create a PR to add newly discovered adapters to the list.
I don't expect the list to change often, so it own't create a lot of noise.