[request] support --disable-gil builds (PEP703)

[tonybaloney]

Description

Please can you add support for building wheels for the --disable-gil version of CPython 3.13.

Similar to debug builds (d), --disable-gil wheels will have an extra suffix (t). The ABI is incompatible with a regular build of CPython 3.13. PyObject has a different data structure.

See pypa/packaging#728 for a related change

Build log

No response

CI config

No response

[joerick]

Cheers Anthony, I was wondering when the need for this was gonna crop up. Given how crucial (and unknown) the C extension ecosystem is to the free-threaded project, I think it makes sense to try to add support for this to cibuildwheel ASAP, so packagers can start trying to build wheels.

I expect the easiest platform to get this working will be Linux, as manylinux already build Python themselves. I'll raise an issue there to see what they think. For the other platforms, the question is how we can get hold of a free-threaded binary build. I think that cibuildwheel building it every time is gonna be too large a cost, so we'd want to get a Mac/Windows build of free-threaded Python from somewhere. Ideally, we start to see them distributed with the alphas.

@zooba, I think you're close to the Python Windows packaging? What's your feeling about CPython distributing a built binary of free-threaded Python, alongside the normal release, in the alpha phase?

[zooba]

I think you're close to the Python Windows packaging? What's your feeling about CPython distributing a built binary of free-threaded Python, alongside the normal release, in the alpha phase?

I am, and obviously we'll do it, but I'm not dropping other work to make it happen myself. There are still big open questions to resolve (e.g. the name, the wheel tag, etc.) and I haven't seen those answered yet (though I'm getting to this post before reading the last week of discuss.python.org, so maybe they have been...)

It wouldn't surprise me if there was a nuget.org release or possibly just a zip file release before an installer-based one, just because of the much greater complexity in handling side-by-side installs of two packages of the same version (which we resolve by changing the package "name", but that has very significant implications for compatibility in MSI bundles, and getting it wrong would very likely leave one or another install irreparably broken). But I think you'd prefer that kind of package anyway? The CI systems are probably set up to use the MSI though, so until we get that sorted out, I wouldn't expect them to preinstall anything else.

[joerick]

Thanks for the response @zooba, that all makes sense to me. You're absolutely right that the nuget package is the one that we'd be most interested in, as that's how we install all the other cpythons, so a free-threaded build on nuget would be ideal for us.