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).
Platforms:
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).
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:
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
Things to cover:
default_cachable_per_repository
and default_relocatable_per_repository
. How do they play with remote repos?Tiggered from https://academysoftwarefdn.slack.com/archives/C0321B828FM/p1661300813516219 and https://academysoftwarefdn.slack.com/archives/C0321B828FM/p1680211147200339.
x86_64
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
packagesarm64
app cannot load a x86_64
library adn vise-versa.# Taken from https://github.com/authlib/demo-oauth-client/blob/master/fastapi-google-login/app.py | |
# | |
# https://www.keycloak.org/getting-started/getting-started-docker | |
# https://www.keycloak.org/docs/25.0.2/securing_apps/#endpoints | |
# https://docs.getunleash.io/how-to/how-to-setup-sso-keycloak-group-sync | |
# https://developer.okta.com/docs/api/oauth2/ | |
# https://github.com/lukasthaler/fastapi-oauth-examples/blob/main/sessions/main.py | |
# https://developer.okta.com/blog/2020/12/17/build-and-secure-an-api-in-python-with-fastapi | |
# | |
# Another (unrelated) resource: https://developer.okta.com/blog/2022/07/14/add-auth-to-any-app-with-oauth2-proxy |
I stumbled on a case where a user of https://pypi.org/project/OpenImageIO/'s wheels on Windows was reporting that they could not import the library in Nuke 14.1.
To debug the issue, I created an EC2 instance with a GPU using the NVidia WinServer 2022 AMI, installed Nuke and tried to import OpenImageIO
. I was able to reproduce immediately.
Let's install OpenImageIO using Nuke's python interpreter:
& 'C:/Program Files/Nuke14.1v6/python.exe' -m pip install OpenImageIO==3.0.3.1 --prefix C:/Users/Administrator/asd
Inside Nuke's script editor: