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:
|
RUN env PYTHON_CONFIGURE_OPTS="--enable-shared --enable-optimizations" pyenv install 3.14.3 && pyenv global 3.14.3 |
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 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.
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
tto the version, e.g.3.14.3t. This might be as simple as adding a3.14tdirectory alongside the3.14one and just updating thepyenv installline:cimg-python/3.14/Dockerfile
Line 45 in f27d139
The
tvariants should work just fine otherwise with the existing Docker configuration here — I’ve been maintaining a set of images for Python pre-releases 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/pythonright now (so far as I’m aware, at least), and it requires building your own base image fromcimg/baseinstead.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/pythonimages that use free-threaded Python, e.g.3.14.3tor3.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.