Support GraalPy

[timfel]

This PR adds support for GraalPy.

A couple of questions:

1. GraalPy is not included in manylinux images, so I added a facility to download Pythons there as well. Does that seem ok?
2. I couldn't find a way to exclude GraalPy by default - I'm not sure, but maybe it would be good to be conservative here and let people opt-in to building wheels on GraalPy via the CIBW_BUILD variable explicitly.

[henryiii]

GraalPy is not included in manylinux images

Would it make sense to include it?

I couldn't find a way to exclude GraalPy by default

Maybe it's time to think about adding this. It comes up occasionally. I'd like to also remove pypy37 and pypy38 from the default, as they are no longer supported by upstream.

[joerick]

GraalPy is not included in manylinux images

Would it make sense to include it?

It would certainly be neater if it was included. Also, I've never heard of GraalPy, so I can't assess wether it's inclusion and maintenance here would be worth it for users. If Manylinux were to adopt it, that would make the decision much easier!

I couldn't find a way to exclude GraalPy by default

Maybe it's time to think about adding this. It comes up occasionally. I'd like to also remove pypy37 and pypy38 from the default, as they are no longer supported by upstream.

Hm. Yes, agreed. It would also allow us to soft-drop EoL CPythons, while keeping the functionality. The simplest way to do this would be to set a default for CIBW_BUILD. E.g. the default could be CIBW_BUILD=cp* pp{39,310}-*. One downside of this would be some projects (example) set CIBW_BUILD to *, for example, in a matrix where some other configurations are set. The fix in such cases, I suppose, would be to set to empty string instead "". On the upside, it does change the default as we want, and doesn't add additional complexity.

[timfel]

GraalPy is not included in manylinux images

I was under the assumption that manylinux (like e.g. conda) wants to build everything into their images from source, but now I see that they also just download PyPy binaries and put them in there, so I can open a PR there to do the same for GraalPy. This will simplify this PR.

The simplest way to do this would be to set a default for CIBW_BUILD [...] the default could be CIBW_BUILD=cp* pp{39,310}-*

That's what I also thought. I did this, which is just skipping any Python specifier starting with g. Rather than a negative match which may exclude too much (with fnmatch we cannot do curly brace expansion iirc, so cannot exclude gp), a positive default may be a good idea, but I'm the wrong person to decide that :)

[joerick]

Converting to draft until manylinux support lands.

[mayeut]

manylinux support has landed. It will be available in cibuildwheel once the update workflow runs & gets merge.

[timfel]

I've updated the PR to use the manylinux support, but in the meantime uv has become included in manylinux and used by default, and that doesn't support GraalPy, yet. See also astral-sh/uv#5141

[timfel]

uv now supports GraalPy on main, once the next release is out we need to include it in manylinux images and then I'll revisit this PR

[mayeut]

Unfortunately, the new version of uv still does not work on manylinux (I commented in the uv PR with more details).
@timfel, you can opt-out from using uv with graalpy for now, c.f. #1941 for a sample opting out PyPy 3.8 on Windows.