[BUILD] Optional numpy dependency missing on pyproject.toml

[JeronimoGRIP]

When installing the Python OpenImageIO bindings there isn't a way to install optional dependencies.

There is a reference to the optional numpy dependency for Python bindings on the install documentation, but there don't seem to be any optional dependencies specified in pyproject.toml.

Would it be possible to add numpy as an optional dependency?

[zachlewis]

Sure -- we could even make Numpy a full requirement, if there's no objection.

(Technically, I don't think Numpy is required at build time to make the bindings Numpy-compatible -- but if Numpy isn't available at runtime, ImageBufAlgo.get_data() will throw an Import Error.)

[lgritz]

I think we should, since NumPy arrays are the way that blocks of pixels are passed around for quite a few of the API calls.

[zachlewis]

Fair enough!

tl;dr - I'll just add "numpy>=1.19," as a requirement.

Just to confirm -- Larry, you're not using the NumPy C API directly, right? Just stuff from pybind11/numpy.h?

If not... this is kind of a rabbit hole.

For posterity...

If I've understood NumPy's guidelines for downstream package authors correctly, since we're not using the NumPy C API directly, we only need to specify a runtime requirement for numpy. This makes things much easier for us.

However -- if we were calling the NumPy C API, we'd want to also add numpy>=2.0 as a build-time dependency, because wheels built against NumPy 2.x are backward-compatible with runtime NumPy 1.x; but wheels built against NumPy 1.x are not compatible with runtime NumPy 2.x. Further confounding things, NumPy 2.x only supports Python >= 3.9, and NEP 29 indicates that Python 3.8 is supported by NumPy >=1.19,<1.22; and the guidelines note, "before NumPy 1.25, the NumPy C-API was not exposed in a backwards compatible way by default. This means that when compiling with a NumPy version earlier than 1.25 you have to compile with the oldest version you wish to support."

🥴

As an aside, NumPy's support "drop schedule" is (understandably) more aggressive than the VFX Reference Platform:

	CY2025	CY2024	CY2023	CY2022	CY2021
glibc	2.28	2.28	2.28	2.17	2.17
Python	3.11	3.11	3.10	3.9	3.7
NumPy	1.26	1.24	1.23	1.20	1.19

Whereas NumPy minor version (non-semver) releases occur every six months; have a support lifespan of 24 months; and support all minor versions of Python released in the past 42 months.

This said, we might want to take this opportunity to cull the Python 3.8 wheels bdists all together, moving forward. Python 3.8 reached EOL in October 2024, and NumPy dropped Py3.8 support with v1.22 (April 2023!). Today, the oldest supported version of NumPy is 1.25, for Python 3.10+.

For shits and giggles, here's SciPy's Toolchain Roadmap, to compare against the VFX Reference Platform's cadence. Between the two, this gives us a general impression of the upper and lower bounds of "toolchain support window" expectations of both the scientific python community and the VFX community.

Riveting.

Takeaways:

• I think we should be fine with just adding a "numpy" runtime requirement.
• We can safely drop the Py3.8 bdist builds

[lgritz]

Just to confirm -- Larry, you're not using the NumPy C API directly, right? Just stuff from pybind11/numpy.h?

Exactly right. OIIO C++ is blissfully unaware of NumPy, but that's what Pybind11 is using when it passes blocks of pixels around.

[lgritz]

We can safely drop the Py3.8 bdist builds

VFX Platform skipped from 3.7 to 3.9, so I don't think we have any VFX Platform constituency that will need 3.8 support.