BLD: build wheels for CPython 3.11

[neutrinoceros]

PR Summary

Upgrade CIBuildWheel now with support for CPython 3.11

In short, CPython 3.11 has reached ABI stability with their first release candidate (3.11.0-rc1), so it's now safe to build wheels for it, even if the final release isn't out yet (expected early October).

Note that numpy has already successfully published some wheels for CPyhton 3.11 (look for "cp311" at https://pypi.org/simple/numpy/) with similar infrastructure.

[neutrinoceros]

it's not working out of the box for win32 + CPython 3.11
I'll follow numpy's similar patch for now numpy/numpy#22102

[neutrinoceros]

So it's actually failing for ALL CPython 3.11 + windows builds.
These are the error messages:

    D:\a\yt\yt\yt\utilities\lib\platform_dep_math.hpp(11): error C3861: '_fpclass': identifier not found
    D:\a\yt\yt\yt\utilities\lib\platform_dep_math.hpp(11): error C2065: '_FPCLASS_NN': undeclared identifier
    D:\a\yt\yt\yt\utilities\lib\platform_dep_math.hpp(11): error C2065: '_FPCLASS_PN': undeclared identifier

For reference, these identifiers are documented as Windows-only:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fpclass-fpclassf?view=msvc-170

and so is the code block where they appear in platform_dep_math.hpp
So it's not clear to me why it's failing specifically with CPython 3.11. There are many places where things can break in the supply chain, but most likely candidates could be CIBW 2.9 and CPython 3.11.0-rc1

[neutrinoceros]

_fpclass, _FPCLASS_NN and _FPCLASS_PN are Windows only symbols defined in <float.h>. It seems that CPython 3.10 and older leak <float.h>, but CPython 3.11 doesn't, hence the fix.

[neutrinoceros]

I checked that the total wheel size doesn't change by removing this line

[neutrinoceros]

this now also clears #4077

[neutrinoceros]

see #4077 here

[neutrinoceros]

@Xarthisius can you have a look ?

[Xarthisius]

I remember that causing problems in envs different than 18.04 too. Is really worth dropping? This way we ensure that shapely builds against the same libraries as cartopy. Unless of course they've fixed all that mess upstream.

[neutrinoceros]

Ah, good call, I guess the comment isn't accurate enough then. I can revert this change.

I also note that we actually install cartopy only on Windows (via conda), so do you think this block should be moved to the windows-only part of the script ?

[Xarthisius]

I thought [full] brings it in?

[neutrinoceros]

It doesn't. That's because cartopy doesn't ship wheels on PyPI, only source distro, and building it from source very often breaks.

[Xarthisius]

OK, but that script is also used in testing right? Cause otherwise why would we add it in the first place if nothing uses it? It must have been failing at some point and that was the fix.

[neutrinoceros]

I suppose it may be a leftover from a time we did try to have cartopy in [full], but honestly not sure. I'm happy to do a pure, conservative revert if you think it's best.

for reference the problem seems to still be real, see

• Minimizing incompatibility between cartopy and shapely SciTools/cartopy#805
• Shapely 1.8.1 causes cartopy to crash SciTools/cartopy#2006

[neutrinoceros]

(I dropped this commit)

[Xarthisius]

Except that one comment LGTM!

[neutrinoceros]

@Xarthisius should someone else take a look too, or is this good to go ?