JeanChristopheMorinPerso

This document lists some ways that we could improve the experience of developing rez.

Tests

• rez-selftest vs unittest vs pytest, etc.
• Coverage isn't working in CI.
• rez-selftest is annoying.
• Better coverage
• Split unit tests and integration tests.

JeanChristopheMorinPerso

Tiggered from https://academysoftwarefdn.slack.com/archives/C0321B828FM/p1661300813516219 and https://academysoftwarefdn.slack.com/archives/C0321B828FM/p1680211147200339.

Facts

• Pre-existing packages are probably x86_64
• Libraries may be fat, ie there’s a single dylib that may support both x86_64 and arm64 (though not exclusive to that)
• arm64 macs can run both x86_64 and arm64 packages, x86_64 macs can only run x86_64 packages
• An app that’s a specific arch cannot load a binary that’s another arch on any of the platforms (some exceptions, but I don’t care to consider them). So an arm64 app cannot load a x86_64 library adn vise-versa.
• An app that’s a specific arch can load a fat library if it has a matching arch within it.
• It could become a thing on Linux or Windows too. But it's hard to know and predict how it would look like.

JeanChristopheMorinPerso

REP-005: Remote package repositories

Things to cover:

• This is laying the ground and doesn't intend to cover everything possible. We expect that future REPs will extend this REP.
• Packing/unpacking (zip, tar, etc) with plugin type
• Package definition database
• Package payload storage
• What about the memcached cache?
• TODO: default_cachable_per_repository and default_relocatable_per_repository. How do they play with remote repos?

JeanChristopheMorinPerso

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 lis

JeanChristopheMorinPerso

Python bindings

py::object as parameter type in class signatures

There is a pattern in the Python bindings (both opentime and opentimelineio) where parameters of type string, list and dict and bool are typed as py::object. The values are converted in the constructors using string_or_none_converter, py_to_vector and py_to_any_dictionary utility functions.

One such example is the Track class:

JeanChristopheMorinPerso

Platforms:

• Linux
• Windows
• macOS

Python versions: 2.7, 3.7, 3.8 and 3.9

OTIO 0.14.0 has 22 wheels produced and uploaded to PyPI (see https://pypi.org/project/OpenTimelineIO/#files).

cibuildwheel