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

[chrisburr]

Test require numpy, matplotlib, ipykernel and more so this will be blocked for a while.

[bollwyvl]

Thanks for the sleuthing, looks like (as of writing) only numpy is in PR (and the county fair image on status currently coming up anvil)

• https://github.com/conda-forge/numpy-feedstock/pull/205

...but the pace seems pretty good!

I, for one, am not particularly excited about pushing out untested stuff, so I am :+1: to wait-and-see, but it would be good optics to have the stack at least partially rocking and rolling for JupyterCon this week... but my greatest fear is that a number of jupyter components haven't been tested on 3.9 at all.

Further, there are some test dependency cycles, which have traditionally made this more complicated, but I don't remember what order they had to be relaxed in order to get stuff out the door... so we have partially relaxed test dependencies in the past to get unblocked (e.g. pypy), and ipy[thon|kernel] (partially accidentally) block a bunch of other things.

If we find we do need this, I can certainly help!

[jakirkham]

@conda-forge/bot, should this still be in the queue given the test dependencies we are still waiting on?

[beckermr]

We have some bugs in the build order right now. Waiting on code review to sort them out.

[jakirkham]

Thanks for the update Matt. Please let us know if there’s anything we should do here 🙂

[dopplershift]

ipykernel depends on ipython for its own test dependencies. Seems like one of those two is going to have to go in without test dependencies... (and the bots haven't sent a py39 PR there)

[Carreau]

I'll see how to update the test command to not require ipykernel.

ipykernel definitely requires IPython, so this one is going to have to pass w.o ipykernel.

[ocefpaf]

For 3.8 I think we commented it out, built and un-comment in the next iteration. If that is OK again we can add a comment explaining this on the line above it. If there is a better solution let's go for it.

[Carreau]

For next release of IPython i'll try to get tests to skip if ipykernel not installed.

https://github.com/ipython/ipython/pull/12617

[Carreau]

Traitlets should be a dependency as well, but has no PR against it yet, how would I debug that ?

[ocefpaf]

Traitlets should be a dependency as well, but has no PR against it yet, how would I debug that ?

That is noarch, right? It should be OK.

[ocefpaf]

The problem is pexpect. PR to fix it in a moment.

[Carreau]

That is noarch, right? It should be OK.

Ah ! Yes, thank you.

[ocefpaf]

@conda-forge-admin, please restart ci

[ocefpaf]

I fixed/restarted pexpect and pickleshare but we still need matplotlib for this one, and probably some more test deps. Looking into that...

Note that matplotlib is noarch:generic b/c it is a metapackage, maybe we should depend on matplotlib-base here?

[Carreau]

Note that matplotlib is noarch:generic b/c it is a metapackage, maybe we should depend on matplotlib-base here?

Happy to, I just made a suggestion to do so. It's just for tests, so we can also stop depending on matplotlib as well, and corresponding test should be skipped.

[dopplershift]

So while that's a better dependency, it won't help get things built on 3.9. Since the matplotlib recipe uses multiple outputs, it's all blocked on pyqt.

[CJ-Wright]

We could consider splitting matplotlib from matplotlib-base at the feedstock level. That would fix this issue. I think the KDE stack has had success in this approach, using solvability checks and a hard pin on the matplotlib-base version would make certain that matplotlib didn't get a version or migration PR before its time.

Addendum: This approach would make a bunch of things more manageable on the graph side, since many packages are still tied to a pyqt build even if they use matplotlib-base.

[bollwyvl]

Given the breadth and depth of the issues we're running into here, perhaps we need a well-known "fast path" template variable, as suggested over on https://github.com/conda-forge/arrow-feedstock/pull/43#issuecomment-707191087. I guess cf-scripts would be the right spot to continue discussion?

In the near term, I'll research the we can already test without circular dependencies...

[bollwyvl]

Right now, it looks like jsonschema is also missing at present... there's an older pr (https://github.com/conda-forge/jsonschema-feedstock/pull/11) to make it noarch, this is probably a good time to make that change...

[ocefpaf]

@conda-forge-admin, please restart ci

[bollwyvl]

Gah, still :broken_heart:. I just got back to seeing what i can relax in the test dependencies behind a building_new_platform flag... requests is still coming up unavailable with build_locally...

[bollwyvl]

.... but reuqests is noarch....

[bollwyvl]

actually mamba says:

Problem: package requests-2.24.0-py_0 requires urllib3 >=1.21.1,<1.26,!=1.25.0,!=1.25.1, but none of the providers can be installed

[ocefpaf]

actually mamba says:

Problem: package requests-2.24.0-py_0 requires urllib3 >=1.21.1,<1.26,!=1.25.0,!=1.25.1, but none of the providers can be installed

Working on it...

[dopplershift]

@conda-forge-admin, please restart ci.

[bollwyvl]

I don't even want to know what dark magic that took...

here's the stuff that I was able to hide and make it work with build-locally.py, looking back through some older migration PRs:

test:
  requires:
    - nbformat
    - nose >=0.10.1
    - pip
    - requests
    - testpath
    # would _ideally_ be in the block below, but messes with re-rendering
    - numpy
    {% if not building_on_new_platform %}
    - curio  # [unix]
    - ipykernel
    - matplotlib-base
    - trio
    {% endif %}

I can go ahead and push, if this seems reasonable?

[bollwyvl]

I'll go ahead and open up another PR...

[bollwyvl]

114 is green except for queued ppc...

https://github.com/conda-forge/ipython-feedstock/pull/114/checks?check_run_id=1249881958

I have to step out for a while, but unless anybody objects, once that clears we should probably merge and move on!