Rebuild for python39

[regro-cf-autotick-bot]

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

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:
imagecodecs
ipykernel
opencv
pandas
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 , 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.

[ocefpaf]

Looks like we need to adapt something in the tests:

E       fixture 'tmp_path' not found
>       available fixtures: Parser, Poly, Poly1, Poly2, add_np, cache, capfd, capsys, check_fpu_mode, doctest_namespace, dtype, endpoint, int_func, monkeypatch, pytestconfig, record_xml_property, recwarn, runner, tmpdir, tmpdir_factory
>       use 'pytest --fixtures [testpath]' for help on them.

That does not sound like a problematic failure.

[jakirkham]

We got a patch release merged here recently. Maybe we can just retry CI?

@conda-forge-admin, please restart CI

[github-actions]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• drone: failed
• travis: passed
• azure: passed

Thus the PR was not passing and not merged.

[xhochy]

The log is too long on mobile but I would guess from the error that the pytest version is too old and we need to wait for the Python 3.9 rebuild on it.

[h-vetinari]

@conda-forge-admin, please restart ci

(conda-forge/pytest-feedstock#126 just finished)

[ocefpaf]

@conda-forge-admin, please restart ci

(conda-forge/pytest-feedstock#126 just finished)

It may take a while for the package to be available. We may need to restart it again.

[h-vetinari]

Though on second thought, this will almost certainly run into the same problem with hypothesis. That package is still waiting for ancestors, and - more problematically - test-depends on pandas, which obviously depends on numpy. Sounds like one of the packages will have to be built without running the full test-suite?

[h-vetinari]

Seems we can get away without hypothesis (should be disabled if not present), but it (still?) picks up a very old pytest version:

+ pytest --verbose --pyargs numpy -k 'not (_not_a_real_test or test_sincos_float32)' --durations=0
/home/conda/feedstock_root/build_artifacts/numpy_1602414569548/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_/lib/python3.9/site-packages/hypothesis/extra/pytestplugin.py:59: HypothesisWarning: 
        You are using Pytest version 3.2.2.  Hypothesis tests work with any test
        runner, but our Pytest plugin requires Pytest  4.3 or newer.
        Note that the Pytest developers no longer support this version either!
        Disabling the Hypothesis pytest plugin...
    
  warnings.warn(PYTEST_TOO_OLD_MESSAGE % (pytest.__version__,), HypothesisWarning)
============================= test session starts ==============================
platform linux -- Python 3.9.0, pytest-3.2.2, py-1.9.0, pluggy-0.4.0 -- $PREFIX/bin/python3.9

I just installed a local 3.9 env, and pytest worked without issue. Seems the cache was updated in the meantime. Let's try again:
@conda-forge-admin, please restart ci

[h-vetinari]

3.9. builds now passed for linux/osx. But I'm thinking the migrator might have wrong meta-data regarding the numpy version?

https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/05f8238fdc1bce6efca505e68347c0a4b4a837a2/recipe/migrations/python39.yaml#L16-L18

Or should we build 1.18 for python 3.9 as well?

[h-vetinari]

All the 3.9 builds are green (the pypy aarch build timed out due to drone being confused with the restarts, I believe), but I think (most) dependent packages will still fail without the availability of 1.18 for 3.9, due to the config of the migrator.

[xhochy]

We should fix the migrator before merging. Then we don't need to fix any generated PRs.

As we don't do rebuilds on new targets with old versions, we should set the numpy version to 1.19 for Python 3.9.

[ocefpaf]

I'm working on a PR for 1.16 which is the version we are pinning.

[isuruf]

We bumped to 1.19 for python3.9 in conda-forge/conda-forge-pinning-feedstock#851

[ocefpaf]

Awesome! I guess that some rebuilds of older version don't hurt but I'm 👍 on bumping the pin.

[h-vetinari]

There's a bunch of numpy-related solver errors in the 3.9 migration, including several high-impact packages like pandas. Any way to retry the migrator for those?

Also, while not critical for the migration, the aarch+pypy build (after merging this PR) timed out on master as well.

[xhochy]

Some builds on master timed out, we need to wait for at least 1-2h until they are up on the CDN and the bot has been rerun.

Seems like the performance on Drone has a very high variance in the last days and some machines are up 4x slower than the rest (seeing this also on the arrow-cpp-feedstock).

[chrisburr]

I expect those were caused by the Windows build failure which has now been retried. I suspect the bot will soon figure out that the problem has been resolved.