Remove constraint on numpy in pyproject.toml?

[mhvk]

In #111, a constraint on numpy was added to pyproject,toml,

pyerfa/pyproject.toml

Line 6 in 1903739

"numpy>=1.25,<2"

This has as a consequence that pyerfa cannot be installed from source any more using older/newer numpy, even though the code itself allows this without problem. And that contributed to it no longer being possible to use the latest version of pyerfa with astropy LTS any more (see astropy/astropy#15481 (comment) and following).

I think this is bad and I would like to remove that constraint while still ensuring that for the wheel builds we do, it is enforced, so that those work with old and new numpy. That should not be difficult but raising this issue to ensure I understand any problems before I do so...

cc @liberfa/pyerfa-maintainers, @pllim

[pllim]

I think removing oldest-supported-numpy is necessary for Python 3.12 support. I also think the real problem here is you no longer provide wheels for that are compatible with numpy<1.25 (#94). https://pypi.org/project/pyerfa/#files vs https://pypi.org/project/pyerfa/2.0.0.3/#files

As long as there are compatible wheel for astropy 5.0.x, it would not need to build from source.

[mhvk]

But I thought the whole point of both numpy API and #94 was "one wheel for all"!? If the wheel doesn't work for numpy < 1.25, that is also a problem.

[astrofrog]

I need to look into this in more detail but I wonder if this is actually a pip version issue - that is old versions of pip don't recognise abi3 wheels?

The version of numpy in pyproject.toml should be irrelevant for other packages as it is meant to be an isolated environment.

[astrofrog]

I can try and look into this tomorrow

[mhvk]

Thanks! Would be nice if it is just a pip issue (and that does seem plausible).

[mhvk]

@astrofrog - it is great that the problems are solved on the astropy side. I'm still a bit confused why exactly the numpy constraint for building is needed, though. It seems particular to wanting a wheel suitable for many python/numpy versions, but why should that be a general constraint on anyone installing from source rather than something we impose in our wheel-building action?

[astrofrog]

It's a good question - I think the reason is because even on an individual user's machine, the user might upgrade/downgrade numpy in the environment and you don't want to have to rebuild all other packages that have numpy as a build time dependency? So even locally we have to build wheels that don't jus work with a single numpy version.