VFX Platform compatibility

[JeanChristopheMorinPerso]

In the last TSC meeting, we discussed about which VFX Platform years we support.

Meeting notes: https://docs.google.com/document/d/14PmEo9ukURmU9OKh4TAo02-e6cSqgnfHFgsURvlqFK8

Excerpt from the meeting notes:

OTIO release 0.14 will support:

• VFX platform 2021, 2020, 2019, 2018
• Python 2.7 - 3.9
• Notice that Python 2.7 is deprecated & we plan to drop it in OTIO release 0.15
• We can still patch things into 0.14.x for folks who need to stay on Python 2.7 VFX 2019, etc.

I thought it would be nice to have a checklist to verify our compliance with the VFX Platform.

• [x] Linux (glibc 2.17): Our Python wheels are built using the manylinux2010 docker images, which use glibc 2.12.
• [ ] Linux: GCC 6.3.1 and 9.3.1. Right now we are testing with 9.3.x that comes with Ubuntu 20.04 (https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#Toolchain_Upgrades_.2B2D3e4P4P-). The manylinux2010 docker images use GCC 8.3.1 which means we also test this version, at least for compilation). We would need to add a job to test against 6.3.1.
• [ ] macOS: We are currently building against 10.15 (and soon 11.0 because GitHub are rolling it out). We need to target 10.13.
• [ ] Windows: Visual Studio 2017 for the VFX Platform 2021. Undefined for previous years. We are currently building with Visual Studio 2019.
• [x] C++: Minimum version is C++14 and maximum is C++17. Are we compliant?
• [ ] PySide2: 2.0.x to 5.15. We currently require 5.11 and higher (https://github.com/PixarAnimationStudios/OpenTimelineIO/blob/master/setup.py#L352)... Do we want to be compliant here?

Notes on Python wheels

While writing this, I had some thoughts about what it means for our Python wheels.

For example, how should we treat our wheels? Do we want to build them inside VFX Platform compliant docker images for our Linux wheels? What about other platforms?

• Linux: I think we should continue to build our Linux Python wheels with cibuildwheel. It uses the manylinux2010 docker image by default, which means our wheels are compatible with glibc 2.17 and higher. In other words I don't think we need to use VFX Platform compliant docker images to build them.
• Windows and macOS: I believe these are not problematic. We just need to change the macOS target to 10.13.

Should we run the unit tests in ASWF docker images? I believe that conceptually we should. But in practice I would say no since it would complicate things. https://github.com/PixarAnimationStudios/OpenTimelineIO/issues/1027 talks about testing our produced wheels, which I think should be done inside the manylinux docker images. cibuildwheel has a functionality to run tests on the generated wheels.

Suggestions

I see these possibilities regarding testing in GitHub Actions:

1. Keep what we have right now and only add some tests for non covered variants of the VFX Platform (i.e. add one job for GCC 6.3.1 and another one for VS 2017). This has the advantage of ensuring OTIO works on multiple Linux distributions. Disadvantage is that our compatibility testing is implicit, in the sense that we have to know that manylinux2010 uses glic 2.17.
2. Keep what we have right now and only add one job for every permutations of the supported VFX Platform years using ASWF docker images for Linux.
3. Drop the ubuntu-20.04 image provided by GitHub and solely use the ASWF docker images on Linux.

---

I hope everything is clear. If something isn't or something is wrong, please let me know and I'll try to clarify and/or fix it. If you think of anything else that needs to be added or disagree with me, feel free to also comment.

[meshula]

Everything here makes a lot of sense to me.

I would want to keep the Ubuntu 20 target irrespective of using the aswf docker images, which I of course support. To my thinking the Ubuntu 20 target covers the "real world" outside of the M&E echo chamber :)

[jminor]

I agree that covering the VFX Platform in addition to (not instead of) the mainstream Ubuntu CI is a good idea.

[meshula]

This issue and it's checklist include vfx2019 and vfx2018. Does it make sense to update the checklist to reflect that, or close this, and start a new issue to cover our current range of 2023-2020? Does a table make more sense than a checklist? Maybe with emojis to indicate status like (a suggestion)

🚀 future ✅ working 🚧 in progress 🐛 borken 👻 not gonna happen

[JeanChristopheMorinPerso]

I'll update it and see if I can improve the clarity. Also, should we add this to the v1 project?

[meshula]

having a vfx platform compatibility matrix as a v1 deliverable gets my vote.