Use oldest-supported-numpy as build dependency?

[takluyver]

I just discovered the oldest-supported-numpy metapackage, meant for use as a build dependency, to build packages against the... oldest supported version of NumPy on any platform & Python version. It tracks the versions we already use pretty closely (except we have NumPy 1.17.5 for Python 3.8, whereas it has 1.17.3). Should we use this?

Advantages:

• Less to update on a new Python version (assuming someone continues to maintain the metapackage)
• More specific rules for which NumPy version to use on e.g. aarch64 or PyPy (see the list here)

Drawbacks:

• No easy way (that I can see) to make the oldest supported numpy the minimum runtime requirement, as we currently do in setup.py. This tells packaging tools not to install h5py with NumPy older than the version it was built with. I don't know how often that would otherwise arise, but it probably avoids at least the occasional bug report.
• Harder to change if we need to specify a different version, e.g. if h5py really needs NumPy 1.17.5 instead of 1.17.3 on Python 3.8. Scipy copies the rules from oldest-supported-numpy instead of using it, probably so that it can set different minimum versions.

[aragilar]

I'm slightly wary of depending on oldest-supported-numpy, mainly because it has come out of the astropy ecosystem, which hasn't always been ideal in terms of the packaging/tooling system they have developed (I would note that I'm biased here: most of my interactions with the astropy ecosystem packaging/tooling have been fixing collogues' systems where they've tried installing something and it has really messed things up...). On the other hand, I think oldest-supported-numpy has been part of their move to a more standard packaging/tooling setup, so maybe it's fine.

[takluyver]

I think it's conceptually the same as what we're doing with build dependencies already. My main hesitation is that I think it's useful to say "build with numpy ==x, install with numpy >=x", and I don't see how you do that without duplicating all of the rules from o-s-n.

I wondered about loading numpy in the setup.py and making a requirement on f"numpy >={np.__version__}". But that's wrong for sdists, so then you have to set up dependencies differently based on whether you're making a wheel or not, which gets messy.