Rebuild for numpy 2.0

[h-vetinari]

This is for testing the migrator; also would need conda-forge/numpy-feedstock#313

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[h-vetinari]

@conda-forge-admin, please rerender

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you but ran into some issues. Please check the output logs of the latest webservices GitHub actions workflow run for errors. You can also ping conda-forge/core for further assistance or you can try rerendeing locally.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/scipy-feedstock/actions/runs/8761682437.

[h-vetinari]

We shouldn't be dropping the pypy (or py312) builds for 1.x. AFAICT this happens because the migrator for those can only add one key, not two (after the duplication here). More details in conda-forge/conda-forge-pinning-feedstock#5790.

[h-vetinari]

@conda-forge/scipy, this is looking alright for everything except PyPy, which fails in three different ways on 3 different platforms - a hang on linux, missing __ror__ on osx (see scipy/scipy#20472) and crashes on windows with

+++++++++++++++++++++++++++++++++++ Timeout +++++++++++++++++++++++++++++++++++
 WARNING: Maximum dimension of Krylov subspace exceeded prior to convergence. Try increasing KMAX.

Note our PyPy builds are also broken on main, so this is not specifically numpy 2.0 related. I'm tending towards dropping PyPy here for now. CC @mattip

[mattip]

I'm tending towards dropping PyPy here for now

Makes sense, it would be nice to have a tracking issue to point to, so if there some interest in picking up PyPy support they have something to start from.

[h-vetinari]

it would be nice to have a tracking issue to point to

Do you mean on the feedstock or in upstream scipy?

Also, I just realised that this is going to play havoc with the migration for any SciPy-dependent feedsfock. Perhaps we should keep PyPy building against 1.x for now (not just for SciPy but in the migrator)?

[mattip]

Perhaps we should keep PyPy building against 1.x

Maybe it is time to drop PyPy from future migrations. Packages that have been built should continue to work, so current users would not be suddenly cut off, and maintainers would not have to deal with the extra headache. I don't see a PyPy3.10 migration happening, and 3.9 is being dropped in the scientific python ecosystem.

[h-vetinari]

Perhaps we should keep PyPy building against 1.x

Maybe it is time to drop PyPy from future migrations.

Those two things are equivalent in this context. Thanks for confirming.