Python wheels

[sanguinariojoe]

This is just a nutshell, to be improved in the future...

I am on the process of integrating this here, as discussed on sanguinariojoe/pip-openexr#11.

The first step, which is just producing the python wheels automagically in this very same repo, is done (look /~https://github.com/sanguinariojoe/openexr/actions/runs/5552026141 (Still running)). Along this line, I already submitted an issue to libdeflate guys to fix a problem which will render the patch needless.

The wheels are uploaded as an artifact, and then they should be manually uploaded to pypi. So probably the next step (after merging this) will be giving you access to the pypi repo. To this end, one of the core developers shall write me a message, so I can give him a simple challenge. Something like uploading a text file on a specific branch.

Then we can think on auto-uploading the Python wheels, which would require to define a protocol. Indeed, versions cannot be overwritten on pypi, so as it is configured right now every single commit on main requires a change on the version. But maybe you prefer to create a stable branch, and build the Python wheels just there... To be figured out

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: sanguinariojoe / name: Jose Luis Cercós Pita (b110f56, ccbe080, 522c8a4, 3da8e25, 1bd9077, 5944c70, 7ec72a9, d6a9eeb, 430d89e, 64f3372, 1a9f7a0, 3e6ce3f, fb74e92, 81441b3, fc6b546, bd85dee, 753886b, fe8085f, eea1217, 9ff4fc7, da15ae3, 429f474, 569c68a, f929767, 8e01bab, 140cc97, 58621ff, e88b0c2, ad5a6d0, 670bd05)

[sanguinariojoe]

Apparently a test failed, but I do not think it is related to my changes. Please, confirm

[cary-ilm]

Thank you for this contribution! We will be happy to accept it. Our bandwidth for this is a bit limited at the moment as we prepare for an upcoming release, but we are definitely interested in integrating the python bindings into official OpenEXR project.

The test failure was indeed spurious, as you suggested, I reran the failed tests and they succeeded.

Would you be willing to consider providing this contribution under the BSD-3-Clause license? That's the standard license used by the project, and it simplifies things to limit the divergence from that. Also, could you append a copyright/license identifier clause as a header in each file? Our standard is:

# SPDX-License-Identifier: BSD-3-Clause
# Copyright (c) Contributors to the OpenEXR Project.

We will need some time to discuss this internally, but we're definitely eager in working out the details.

[sanguinariojoe]

Our bandwidth for this is a bit limited at the moment as we prepare for an upcoming release, but we are definitely interested in integrating the python bindings into official OpenEXR project.

No prob, take your time. As I told you this is just a nutshell, so a whole line of working will be arising from this PR.

Would you be willing to consider providing this contribution under the BSD-3-Clause license? That's the standard license used by the project, and it simplifies things to limit the divergence from that. Also, could you append a copyright/license identifier clause as a header in each file?

Sure thing! I did that on 670bd05

[cary-ilm]

Thanks for the contribution. We're preparing for a 3.2 release in mid-August, but we'll follow up after that regarding the process of uploading to pypi.

I think this build workflow can be simplified a bit, I'll follow up separately about that.

Regarding the POSITION_INDEPENDENT_CODE patch for libdeflate, I see the ebiggers/libdeflate#317 issue is still open. I haven't experimented with it yet, but do you see any reason the suggested CMake option won't suffice?

[sanguinariojoe]

The option is just perfectly fine. The notification just went under my radar...

Would you please add that option and remove the patch yourself?