-
Notifications
You must be signed in to change notification settings - Fork 288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VFX Platform compatibility #1094
Comments
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 :) |
I agree that covering the VFX Platform in addition to (not instead of) the mainstream Ubuntu CI is a good idea. |
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? 🚀 future |
I'll update it and see if I can improve the clarity. Also, should we add this to the v1 project? |
having a vfx platform compatibility matrix as a v1 deliverable gets my vote. |
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:
I thought it would be nice to have a checklist to verify our compliance with the VFX Platform.
glibc
2.17): Our Python wheels are built using themanylinux2010
docker images, which use glibc 2.12.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.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?
cibuildwheel
. It uses themanylinux2010
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.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. #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:
manylinux2010
uses glic 2.17.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.
The text was updated successfully, but these errors were encountered: