CircleCI-Public / CircleCI-Public/cimg-python
Feature Request: Support free-threaded Python
- Dominant language
- Dockerfile
- Stars
- 36
- Forks
- 33
- PR merge metrics
- No merged PRs in 30d
Description
**Describe the Feature Request**
Python has been officially supporting a free-threaded variant since v3.14.0 (also available in v3.13.x, but it was considered experimental then). That is, multiple threads in Python no longer invoke the GIL to coordinate, which reduces performance limitations significantly. Because it can cause subtle issues in programs that do not do all the correct locking and coordinating, it’s important to be able to test these builds in CI. More info on free-threaded builds here: https://py-free-threading.github.io/
Free-threading is a build-time feature, so it would need to be a separate Docker image/tag. As far as I can tell, this isn’t currently being built here or published at https://hub.docker.com/r/cimg/python.
The official free-threading variants are usually identified by appending a `t` to the version, e.g. `3.14.3t`. This might be as simple as adding a `3.14t` directory alongside the `3.14` one and just updating the `pyenv install` line: https://github.com/CircleCI-Public/cimg-python/blob/f27d1395d07d077c5fe6e681e0ab7c9e53e9c7d1/3.14/Dockerfile#L45
The `t` variants should work just fine otherwise with the existing Docker configuration here — I’ve been maintaining [a set of images for Python pre-releases](https://github.com/Mr0grog/circle-python-pre) for a couple years that does free-threaded builds without issue (I changed the Dockerfile slightly to accommodate Poetry failing to build, which regularly happens in pre-releases before the release candidate phase, but it’s never failed on final releases of Python).
**Is your feature request related to a particular problem?**
The free-threaded variant of Python can cause lots of subtle issues with any Python’s binary interface (e.g. compiled extensions/packages written in C), it’s really important to test against in CI. Even pure-Python packages may have binary dependencies, or may just need to be more careful about locking and testing in threading-related code.
None of this can be tested in Circle when using `cimg/python` right now (so far as I’m aware, at least), and it requires building your own base image from `cimg/base` instead.
**How will this feature request benefit CircleCI jobs using this image?**
It enables testing free-threaded Python without building custom base images.
**Describe the solution you would like to see**
I would like to see tags for the `cimg/python` images that use free-threaded Python, e.g. `3.14.3t` or `3.14.3t-node`.
**Describe alternatives you have considered**
The alternative is all customers testing Python code building custom base images for free-threaded Python and not being able to rely on `cimg/python`.
Contributor guide
Assessment
This issue has not been assessed yet.