Thanks @h-vetinari

Cool! Should we backport this to 1.22?

Cool! Should we backport this to 1.22?

Yes. vs2019 should be good until 2024 (IIRC). If we want consistency, might want to change the wheels builds as well. Scipy-wheels build on appveyor using vs2017.

Scipy-wheels build on appveyor using vs2017.

Are we talking about https://github.com/MacPython/scipy-wheels? There are no windows jobs in that repo (anymore?). When I researched the scipy windows build infra at the time of scipy/scipy#13713, all signs pointed to the fact that these were built in the main repo, and this passed review at the time. I'm more than happy to correct that info if I was wrong of course - perfect chance with scipy/scipy#15167

See appveyor.yml at https://github.com/MacPython/scipy-wheels.

That said, it might be easier for someone used to the repository. @tylerjereddy @rgommers Thoughts?

Ah, sorry, I overlooked this. Thanks for the pointer!

@ Ralf & Tyler

Is there a reason not to use azure-pipelines for the windows builds as well? I'm worried that the gap between the CI on the main repo (VS2019) and on the wheels-repo (VS2017) will soon lead to divergences that are a big timesink. Alternatively, the wheels-repo would have to move to VS2019 as well, at which point the question arises why not azure-pipelines directly?

Perhaps scipy would be interested in adopting the work to use cibuildwheel in numpy, xref tracking issue #20262

Yes, we are not attached to Appveyor and would be happy to get rid of it. Either as a one-off migration to Azure, or as part of a larger cibuildwheel overhaul. The latter should happen over the next year, but not clear when exactly.

or as part of a larger cibuildwheel overhaul. The latter should happen over the next year, but not clear when exactly.

@rgommers
Is there an issue/thread/repo to track this? Searching for cibuildwheel here, I only found a more recent comment:

To be considered after the ongoing migration to cibuildwheel is complete.

... which also doesn't yield much more insight, though #20102 looks like some progress was made already, and that @lithomas1 has some PRs (both merged and open) in that area.

I see that some repos under https://github.com/MacPython already use cibuildwheel, but also that some are moving wheel-building directly to the main repo. Is that the goal for numpy/scipy as well?

Background: I wanted to get restart the efforts to update scipy wheel builder (vendored gfortran, vs2019, etc.), and wanted to gauge if I should wait/not wait for (or somehow contribute to) the cibuildwheel stuff.

Ping @rgommers

Should I perhaps open an issue to track the cibuildwheel migration/integration?

Should I perhaps open an issue to track the cibuildwheel migration/integration?

That may be useful as a SciPy issue. That said, the plan is "wait till NumPy is completely done with the migration, then just copy the NumPy setup to SciPy". And since NumPy is not yet done, I'm not sure there is anything to do right now.

The thing is I wanted to know primarily is the status and if makes sense to wait for it / contribute to it...

Waiting then I'd say. Copying things over should be quick, because the numpy/scipy setups are very similar.

The last two pieces are

• getting the uploads to work (BUILD: simplify upload step #21043) and
• adding aarch64 wheels to travis-ci (BLD: Try adding aarch64 wheels [wheel build] #20987).

I think I also need to add something to build the sdist(This is pretty easy and I'll try to put up a PR sometime this week).
We are also considering adding universal2 wheels.

Yes, building the sdist would be great! We've always done that in the wrong way.