numpy 1.23.2 will not build with GCC 13, need to bump requirement version so scipy can build about scipy HOT 4 CLOSED

It isn't immediately clear to me that we'd want to bend over backwards to support a super-new gcc version in these kinds of scenarios. Usually the idea is to have the default isolated-build of a wheel via pip occur via a "maximally-compatible" set of dependencies, rather than trying to support bleeding edge.

If you have a special need to do this, and even if you're working on a Linux distribution, I'm pretty sure our standard recommendation is to just turn off build isolation and then you can use whatever deps you want to build a wheel (at your own peril, of course); i.e., pip install . --no-build-isolation

https://scipy.github.io/devdocs/dev/toolchain.html may also have some useful info.

For an even deeper dive, re: pyproject.toml handling external deps like compiler versions, see the PEP that Ralf co-wrote: https://peps.python.org/pep-0725/#version-specifiers-for-purls

We've had other issues a bit like this that turned into long debates with Linux package distributors..

from scipy.

That said, we do have the option to sidestep a lot of this stuff because of: https://numpy.org/doc/stable/release/1.25.0-notes.html#compiling-against-the-numpy-c-api-is-now-backwards-compatible-by-default

Although, I don't think we will necessarily push for that in 1.12.0; currently has the older-style NumPy version pins.

from scipy.

i.e., pip install . --no-build-isolation

Indeed, that's the straightforward workaround for now.

Although, I don't think we will necessarily push for that in 1.12.0; currently has the older-style NumPy version pins.

Yes, I think we should do this for 1.13.0, which should arrive in February or so (with NumPy 2.0 compat). That will structurally solve this type of problem.

I'll close this issue, because there is nothing to be done right now, and turning off build isolation is the answer for now.

from scipy.

Well, that's definitely a more painful way of doing it, but probably doable. I'm trying to build a mirror with pypi-mirror and it's a lot easier to just say "give me scipy" then it is to say "give me scipy", figure out the right dependencies and say "get ... too".

Anyway, my workaround was to just update python and then it pulled in the right version anyway. Not sure what you mean by "maximally-compatible" as you're using it with python3.12, but w/e, I've got my workaround and I'm moving on.

from scipy.