search

afichet / openexrpython

OpenEXR bindings for Python
Other
1 stars 1 forks source link

Create a new openexr3 package? #1

Open meshula opened 2 years ago

meshula commented 2 years ago

Hi Alban!

There's an urgent need for a new package release, we get frequent bug reports on this binding in the main OpenEXR repo, even though we are unable to resolve issues there, and must refer problems to the python binding repo for resolution.

It's very nice to see an upgrade of this package to OpenEXR 3.

As a member of the OpenEXR TSC, one bit of experience I'd like to share about the OpenEXR 2 to 3 migration, in both C++ and Python, is that it happens that people need both versions of OpenEXR to coexist due to a huge amount of legacy baggage in their own environments.

Since development on the main repo hasn't moved in some time, I'd like to propose that your new repo generate a NEW package called openexr3, which can then be distributed via pypi. Also, I would propose that github actions be introduced here to create CI for publishing wheels to pypi on demand, or when releases are tagged.

My idea is that a release of openexr3 could be structured in such a way that openexr (2) and openexr3 could happily co-exist in a user's site-packages.

Then, when people encounter the problems of using the existing openexr package in an environment where they need to be on OpenEXR 3, because they are moving forward with their vfxplatform compatibility, for example, the advise would be to simply pip install openexr3, and add a line of code in their existing scripts along the lines of import openexr3 as openexr.

When that works, then a PR could be generated back to the original project for @jamesbowman to consider. Whether or not it's appropriate to merge back to the original project, or whether there should be a new openexr3 project, I think it's a good move to allow the original to exist in site-packages for openexr 2 support, alongside a new project.

afichet commented 2 years ago

Hi Meshula!

Sorry for my late answer, missed the issue...

That is an excellent idea to have a different package name allowing the two version to live next to each other.

I'm unfortunately not familiar with Python packaging but will try to make this happen in the following weeks.

Cheers.

meshula commented 2 years ago

Sounds great!

On OpenTimelineIO, Jean-Christophe Molin engineered a solution to automate releases to PyPi, triggered by tagging a release.

An approach like that might allow the PyPi bindings to automatically track OpenEXR releases via GitHub actions and they'd never go out of sync.

That's a good reference point to see what all the moving parts are. He's on the ASWF Slack, so that might be a good place to ask questions, perhaps in #openexr.