Rebuild for pypy

[regro-cf-autotick-bot]

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

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:

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 code>@<space/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/662961176, 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.

[henryiii]

Looks like NumPy 1.16 -> 1.17 which is why the build number bump. Otherwise is mostly just adding CPython to CI file names.

[jakirkham]

Yeah it's because we skip it

https://github.com/conda-forge/numba-feedstock/blob/aa5136c2f2b2f809f33f80650377bbf38ef4f8bc/recipe/meta.yaml#L24

Should we drop the skip? It might make it more obvious to us that it doesn't work (IOW CI will fail)

[henryiii]

Numba doesn't support PyPy, so this will stop us from getting stuck on PyPy migrations we can't take part in. I think the changes are correct, such as bumping the NumPy version. The conda-forge docs clearly say to skip PyPy if you don't support it.

[jakirkham]

Where do you see this in the docs?

We won't be able to merge the PR in either case. Otherwise the migration bot will think that this package will be migrated. Unfortunately every time we merge a PR this PR will get closed and resubmitted by the bot. So the discussion here will get lost and people may incorrectly think this works. The fact it passes despite not doing anything might get lost on us or someone else in the future.

If we don't have a skip, the build will at least fail on CI, which will make it clearer that PyPy doesn't work on this feedstock. This should protect against bad merges.

[henryiii]

https://conda-forge.org/docs/maintainer/knowledge_base.html#pypy-builds - it says to skip PyPy if unsupported. And we will have "passed" the migration - we now have the ability to render in PyPy support; we just won't, since Numba doesn't and may never support PyPy.

Are you sure the bot will resubmit? I believe a merge counts as a successful migration, as does closing this PR without a merge. That's why Python 3.9 was "passed" for Numba for some time, I incorrectly closed the Python 3.9 bot PR, and that counted as "passing" the migration.

The point of the migration is to enable the possibility of running PyPy (or Python 3.9, etc) builds, it does not mean you have to use them if you don't support them. Before the migration, we could not have added a PyPy build, there was no way to do it. After merging this, we could remove the skip, and the next rerender would add PyPy builds.

[jakirkham]

Are you sure the bot will resubmit? I believe a merge counts as a successful migration, as does closing this PR without a merge. That's why Python 3.9 was "passed" for Numba for some time, I incorrectly closed the Python 3.9 bot PR, and that counted as "passing" the migration.

Yep. In fact the bot closed PR ( https://github.com/conda-forge/numba-feedstock/pull/70 ) and resubmitted as PR ( https://github.com/conda-forge/numba-feedstock/pull/72 )

Edit: Right we can't close it as that will count as completed, but the bot does close PRs that are out-of-date and resubmits them automatically. This is usually a good feature with the exception being cases where we can't migrate the feedstock (like with numba)

[henryiii]

No, the bot only resubmits if the bot closes it. If we close it (by merge or manually), the migration will be complete. I believe the migration is about adding the CI infrastructure (which is exactly what this PR does), not about forcing packages to support PyPy or forever rebuilding a PR on every change to master.

[henryiii]

Opened an issue to discuss this in terms of the infrastructure, as currently the wrong thing will be done if this is merged (new PRs will be opened on the 58 dependent projects. :'( )

[jakirkham]

Thanks for doing that :)

Yeah I think we are saying the same thing in terms of bot behavior

In any event there’s an edge case in migration that currently isn’t handled. Namely when something shouldn’t or can’t be migrated. Collecting a bunch of open PRs for these that can’t be merged or closed is not ideal

[henryiii]

Making this draft until it is resolved (or the bot rebuilds it 🤦 )

[jakirkham]

This migration is outdated. Asking bot to rerun to clear it out

[regro-cf-autotick-bot]

I see that this PR has conflicts, and I'm the only committer. I'm going to close this PR and will make another one as appropriate. This was generated by https://github.com/regro/autotick-bot/actions/runs/3146078318