conda-forge/conda-forge.github.io

Separate build mode for Python without a GIL is coming (eventually)

h-vetinari opened this issue · 7 comments

PEP 703 is on the way to acceptance. 🥳

It's not an immediate concern (earliest availability will be 3.13), but I'm guessing we'll have to decide if/how we want to add support. At the time nogil gets added, this amounts to one extra python job (e.g. py310, py311, py312, py313, py313n), but as time goes on (and before nogil becomes the only supported variant way down the line), this would eventually double our build matrix.

I'm not expecting discussion/decisions now, but wanted to open an issue for reference.

isuruf commented

We can have a no GIL version for the latest python version only until it becomes the default which I assume will be for a python version update and not for versions already released.

We can have a no GIL version for the latest python version only

Do you mean something like:

py310, py311, py312, py313, py313n
py311, py312, py313, py314, py314n
py312, py313, py314, py315, py315n

? That's a good idea! Perhaps with a transition where we keep the "old" nogil pyver around while the new version is being migrated.

What is the ABI compatibility?

Will these be like pypy with a migration job and a separate Abi build?

Will these be like pypy with a migration job and a separate Abi build?

The details are still being figured out but that's the expectation.

Yeah the ABI itself may change between here and Python 3.13 (or 3.14 if it slips)

There were at least a couple people asking for a runtime configured solution, which would mean no ABI change (not sure how viable that would be though)

The current implementation is definitely not ABI-compatible. AFAIU it even changes the stable ABI, which would normally require a major version. Not sure how that circle will be squared, but I think it's reasonable to expect a separate ABI.

It's still very early in the game though, so we'll just have to wait and see a bit.