3 missing pypy builds for 1.7.0

[h-vetinari]

See discussion in #169, culminating in this comment:

That means 1.7.0 has now been built for all but the following three variants:

• pypy37 on linux / x64
• pypy37 on linux / ppc
• pypy37 on osx / x64

[mattip]

I think the PyPy crash is due to a huge stack allocation when entering a function, cython/cython#4272. I don't understand what the difference is between CPython and PyPy.

[h-vetinari]

The PPC build will need some encouragement (=restarts), keeping this open until then.

[mattip]

I think windows64 pypy migration is missing as well?

[h-vetinari]

Yes indeed, but I wasn't counting that since the migrator still needs to chew through a bunch of dependencies first

[mattip]

Is the migrator still active? At https://conda-forge.org/status/ I see it is listed under "Recently closed migrations" as "pypy37-windows closed at 2021-07-07"

[h-vetinari]

See my comment here

[h-vetinari]

I cannot get the pypy build on PPC to pass despite >5 restarts. Perhaps it needs some of the recent fixes on the pypy-feedstock (and PPC needing manual rebuilds)

[mattip]

I personally would be happy to drop ppc and s390x support for PyPy on conda forge. At least until we get a little more experience around the use case for PyPy on x86/arm64.

[isuruf]

travis is supposed to run only a fraction as in https://github.com/conda-forge/scipy-feedstock/blob/master/recipe/run_test.py#L19-L21. Not sure why that doesn't get triggered.

[h-vetinari]

@isuruf, it's not a question of runtime. The build regularly fails with:

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.

Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received

It could just be extreme flakiness on the side of travis, but it could equally be a hang caused by the pypy builds. If you could rebuild the current pypy-recipe for aarch&ppc, we could test that hypothesis. Otherwise, I tend to agree with Matti; PPC is already <0.1% of downlods, and pypy-on-PPC is <0.01% of downloads, cf. #171

[rgommers]

+1 for disabling PyPy on PPC, too niche to be worth even this current effort.

[isuruf]

Problem with disabling now is that downstream packages will need to disable that platform manually which I want to avoid.

Maybe we should try cross compiling so that we can move away from Travis-CI. Travis-CI has been extremely flaky lately.
I'll see if I can get cross-python to support PyPy. Might need changes in PyPy.

[h-vetinari]

I've tried cross-compiling in Azure, but that creates ~2000 test suite errors in the test suite (not just for PyPy), see here.

[h-vetinari]

Maybe we should try cross compiling so that we can move away from Travis-CI.

See #179

[h-vetinari]

Unexpectedly, cross-compilation on ppc now works without issue. This will be solved as soon as #182 is merged.