Ah, there's no NumPy wheel, we should probably bump that first.

NEP 29 says we should be on NumPy 1.19 already; we're still on 1.17. I hope the two release bump is okay?

I think jumping 2 versions is OK. The mistake was not bumping earlier, no reason to compound that by not bumping far enough now.

There are not wheels for pillow6.2.0 for py38 but there are for 6.2.1

I tried building witholdest-supported-numpy, but that installed an older version on Python 3.8, and thesetup_requires bumped it to the latest, which didn't have wheels, so I had to do a fixed version there.

Also, disabled PyPy temporarily as the version of cibuildwheel that supports it breaks Windows builds, which I need to investigate and report upstream.

But otherwise,the wheels are building.

And AppVeyor doesn't have a 3.9 miniconda, so I just went with the default one instead.

Addingimage: "Visual Studio 2022" should switch us to a new image that has a py38 miniconda.

It also looks like they have a bunch of "system" python build (https://www.appveyor.com/docs/windows-images-software/#python) if we update the image. I am not sure if we want to keep appveyor on conda (so we can test that things work as exected in conda), move it to the system Python or just drop appveyor all together.

Addingimage: "Visual Studio 2022" should switch us to a new image that has a py38 miniconda.

Yes, but there's still no 3.9 one.

Not sure why Tk is missing on macOS for Python 3.10; is anyone running 3.10 on a mac that can check?

I have no issues with tk locally, from a fresh Python 3.10 installation from the release page.

I also don't have any issue with a conda python3.10 environment and running the interactive tests. It may be due to the MacOS 11 image...
https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml

I think the right fix here is to be more careful about assuming tk is available in the tests.

Seems to be a bug Azure environment:actions/runner-images#4931

So here it's failing intest_backends_interactive because of missing TkAgg. There is a skip, but the problem is it just checks that the package exists, and doesn't attempt an import, probably to avoid conflicts. The failure here is that it cannot be imported, not that it doesn't exist.

I don't know if we want to try harder to skip these sorts of errors (Azureshould be deploying a fix this week some time), as it might require some extra communication from the subprocess to the main test. Maybe the changes in#22005 would make it easier?

I think one of later commits in#22005 will correctly skip tk in this case (but it is failing on the py37 issues again).

It looks like the fixes were tagged yesterday, but just haven't been rolled out to all builders yet.

They needed another fix; rollout is this week some time (I guess starting on the 9th probably.)

Deployment is around 99.9%, but it's close enough to get our build working. By the time this is merged, their fix will probably be out on all Azure machines.

Looks like the upstream got resolved. I'll hold off on merging in case you were waiting on any other runners/updates. Feel free to self-merge.