Rebuild for pypy37

[regro-cf-autotick-bot]

This PR has been triggered in an effort to update pypy37.

Notes and instructions for merging this PR:

1. Please merge the PR only after the tests have passed.
2. Feel free to push to the bot's branch to update this PR if needed.

Please note that if you close this PR we presume that the feedstock has been rebuilt, so if you are going to perform the rebuild yourself don't close this PR until the your rebuild has been merged.

This package has the following downstream children:
cryptography
aiohttp
pytest
ipython
lal
And potentially more.

If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase @conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

_{This PR was created by the regro-cf-autotick-bot.
The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. If you would like a local version of this bot, you might consider using rever. Rever is a tool for automating software releases and forms the backbone of the bot's conda-forge PRing capability. Rever is both conda (conda install -c conda-forge rever) and pip (pip install re-ver) installable.
Finally, feel free to drop us a line if there are any issues!
This PR was generated by https://github.com/regro/autotick-bot/actions/runs/467271952, please use this URL for debugging}

[conda-forge-linter]

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]

No idea why this was opened so early, but this is blocked at least on conda-forge/pytest-feedstock#132 and (obviously) on numpy.

[h-vetinari]

@conda-forge-admin, please restart ci

(After conda-forge/numpy-feedstock#222)

[h-vetinari]

Pypy is timing out on drone (not sure if a restart would help...?), rest looks good

[simonjayhawkins]

not sure if a restart would help...?

restarted

[h-vetinari]

@simonjayhawkins: restarted

Thanks, but it looks like it will time out again. pypy on aarch is probably niche enough that it shouldn't hold up everything else? @conda-forge/arm-arch @conda-forge/pypy-meta

[xhochy]

We can cross-compile pandas on aarch64 instead? This would have the drawback though that we wouldn't run the tests for it but would speed up the build.

[hmaarrfk]

The extensions don't seem to be cythonizing in parallel. One can try to invoke bulid_ext in parallel.

-j{CPU_COUNT} might help with a command similar to:
https://github.com/conda-forge/scikit-image-feedstock/blob/master/recipe/meta.yaml#L27

[h-vetinari]

@hmaarrfk
That's already being used: https://github.com/conda-forge/pandas-feedstock/blob/master/recipe/meta.yaml#L16

Might have to go with @xhochy's suggestion, or just skip pypy on aarch.

[hmaarrfk]

I also got this problem for imagecodecs. Are we expecting to cross compile all cython packages?

Seems like a lot.

Is cython known to be slow to compile on puppy?

[xhochy]

Is cython known to be slow to compile on puppy?

This looks really weird. I first thought that was a slow machine and restarted the build but it has the same performance on the second run.

[h-vetinari]

Is cython known to be slow to compile on puppy?

This looks really weird. I first thought that was a slow machine and restarted the build but it has the same performance on the second run.

Apparently, there's a faster and a slower machine (from here):

@h-vetinari: The last drone job timed out - I've seen this pattern a lot in the blas-variant PRs: 2-3 drone jobs go through in 25-30min, the ones beyond that get less resources(?) and then ultimately fail at the 60min timeout (somewhere between finishing the build and the middle of the test suite).

@beckermr: There are two different machines that drone runs jobs on. One is faster than the other I think? @isuruf has details

[hmaarrfk]

@xhochy my builds on imagecodec are also very slow for the same reason

conda-forge/imagecodecs-feedstock#22

Maybe we need to limit the CPUs for PyPy? Maybe PyPy can't handle 48 cores.

[hmaarrfk]

I rebuilt it enough times in drone and finally got lucky with imagecodecs. maybe you will get lucky with this too.

[h-vetinari]

I rebuilt it enough times in drone and finally got lucky with imagecodecs. maybe you will get lucky with this too.

From experience, which one of the jobs fails is pretty random, so restarting it 2-3 times on master should be enough to also build the 4th one that will fail with the first build after merging.

[h-vetinari]

BTW: It would be very useful for the already strained drone build queue if restarts could be done per job, and wouldn't restart all of them (within a build) at the same time @isuruf.

[hmaarrfk]

I'm building pypy on a local native machine. Hopefully we will have this resolved soon.

[hmaarrfk]

Something really weird is happening after the installation gets to

    Compiling pandas/io/sas/sas.pyx because it changed.

Its just kinda stuck there for a while.

[hmaarrfk]

@isuruf result is located /home/hmaarrfk/mambaforge/conda-bld/linux-aarch64/pandas-1.2.0-py37h157fc04_1.tar.bz2

In the machine

Linux conda-forge 4.14.0-115.2.2.el7a.aarch64 #1 SMP Wed Nov 28 22:05:51 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

[isuruf]

Thanks. Uploaded

[h-vetinari]

Thanks. Uploaded

So if the aarch + pypy file has been uploaded, why not merge this PR? 🙃

[hmaarrfk]

i can't, and thus a maintainer should.