PEP 703: actions/setup-python python3.13t builds with --disable-gil
#771
Comments
hugovk
added
feature request
|
Hello @hugovk. Thank you for your feature request. We'll take a look on it. |
|
Hello @dmitry-shibanov, any news? The 3.13 beta is due on 2024-05-07 and we'll ask the community to start testing ahead of the full release in October. It would be very helpful if it's possible using GitHub Actions. Thanks! |
|
@dmitry-shibanov hi! 3.13 beta 1 was just released. Myself and a few others have been working on adding compatibility for free-threaded python builds and I'd like to start adding CI for some projects in the scientific python ecosystem. Being able to specify a build via |
|
@dmitry-shibanov Thanks for looking into making this happen. Is there anything you need from the Python community to make this happen within GitHub Actions? |
|
For anyone seeking a workaround the deadsnakes action has a nogil flag https://github.com/deadsnakes/action You can install Python 3.13 this way as a drop in replacement for the setup-python action. |
|
I had a first look at how it could be implemented given the current state of things in actions:
That being said, the This is probably not user friendly so while the I'm willing to submit Pull Requests but need some guidance regarding what's acceptable from the maintainers first. |
|
I’m curious, with Python 3.13 now being in the release candidate phase, is anyone still working on this or discussing it? |
|
I'm also curious if anyone has worked on this yet. For Windows, at least, the e.g. here is how I've installed the 3.13rc1 nogil binary with a powershell script: |
Python 3.13 has reached rc1, this PR adds it to the test matrix. Note: not using free-threaded builds at this point due to actions/setup-python#771 (not like we'd expect any difference, frankly)
|
Maybe it would be a good idea to add |
|
As a workaround, I'm currently using |
hugovk
changed the title
--disable-gil--disable-gil
|
Python 3.13.0 final has now been released: 🚀
Done. |
|
There's also the deadsnakes github action: https://py-free-threading.github.io/ci/ |
|
Meanwhile I'm using a multi-distribution image (Debian+pyenv) with CPython 2.7, 3.5-3.14a2 (includes free threading). Just in case someone wants to try it out: makukha/multipython |
Python wheels, pyenv, and a number of other tools use 't' in the Python version number to identify free threaded builds. For example, '3.13t', '3.14.0a1', '3.14t-dev'. This PR supports that syntax in `actions/setup-python`, strips the "t", and adds "-freethreading" to the architecture to select the correct Python version. See actions#771
Python wheels, pyenv, and a number of other tools use 't' in the Python version number to identify free threaded builds. For example, '3.13t', '3.14.0a1', '3.14t-dev'. This PR supports that syntax in `actions/setup-python`, strips the "t", and adds "-freethreading" to the architecture to select the correct Python version. See actions#771
* Support free threaded Python versions like '3.13t' Python wheels, pyenv, and a number of other tools use 't' in the Python version number to identify free threaded builds. For example, '3.13t', '3.14.0a1', '3.14t-dev'. This PR supports that syntax in `actions/setup-python`, strips the "t", and adds "-freethreading" to the architecture to select the correct Python version. See #771 * Add free threading to advanced usage documentation * Fix desugaring of `3.13.1t` and add test case. * Add freethreaded input and fix handling of prerelease versions * Fix lint * Add 't' suffix to python-version output * Use distinct cache key for free threaded Python * Remove support for syntax like '3.14.0a1' * Clarify use of 't' suffix * Improve error message when trying to use free threaded Python versions before 3.13
|
Hello everyone 👋, |
|
Thank you @priya-kinthali and @priyagupta108 for the reviews and feedback! |
See gitpython-developers#2005. Right now, this does not limit by operating system, but that is just to verify that there are no OS-specific 3.13t problems we should know about right now; once that is verified, the macOS and Windows jobs will be removed (excluded) for the time being. The 3.13t jobs added here use `Quansight-Labs/setup-python`, not `actions/setup-python`. The latter also has the ability to use 3.13t since actions/python-versions#319 and actions/setup-python#973 (see also actions/setup-python#771), but no version tag includes this feature yet. It can be used by using `@main` or `@...` where `...` is an OID. The former would risk pulling in other untested features we're no trying to test with, while the latter would not be easy to upgrade automatically as what we have now (we would be deliberately keeping a hash not at any tag that is already not the latest hash on any branch). In contrast, the `Quansight-Labs/setup-python` fork adds this feature while staying up to date with others. When `actions/setup-python` has a release (stable or prerelease) with this feature, we can switch to it. This could probably be done with less code duplication by using a matrix variable for the action to use. Instead, the "Set up Python" step is split in two, with opposite `if` conditions, so that each is capable of being recognized and upgraded by Dependabot if a new major version is released (in case this ends up remaining in place longer than expected).
|
Hi, is there any release schedule to allow developers access this feature via a git tag? |
See gitpython-developers#2005. Right now, this does not limit by operating system, but that is just to verify that there are no OS-specific 3.13t problems we should know about right now; once that is verified, the macOS and Windows jobs will be removed (excluded) for the time being. The 3.13t jobs added here use `Quansight-Labs/setup-python`, not `actions/setup-python`. The latter also has the ability to use 3.13t since actions/python-versions#319 and actions/setup-python#973 (see also actions/setup-python#771), but no version tag includes this feature yet. It can be used by using `@main` or `@...` where `...` is an OID. The former would risk pulling in other untested features we're no trying to test with, while the latter would not be easy to upgrade automatically as what we have now (we would be deliberately keeping a hash not at any tag that is already not the latest hash on any branch). In contrast, the `Quansight-Labs/setup-python` fork adds this feature while staying up to date with others. When `actions/setup-python` has a release (stable or prerelease) with this feature, we can switch to it. This could probably be done with less code duplication by using a matrix variable for the action to use. Instead, the "Set up Python" step is split in two, with opposite `if` conditions, so that each is capable of being recognized and upgraded by Dependabot if a new major version is released (in case this ends up remaining in place longer than expected).
|
This has now been released as v5.5.0 and v5:
I wrote up some instructions: |
* Support free threaded Python versions like '3.13t' Python wheels, pyenv, and a number of other tools use 't' in the Python version number to identify free threaded builds. For example, '3.13t', '3.14.0a1', '3.14t-dev'. This PR supports that syntax in `actions/setup-python`, strips the "t", and adds "-freethreading" to the architecture to select the correct Python version. See #771 * Add free threading to advanced usage documentation * Fix desugaring of `3.13.1t` and add test case. * Add freethreaded input and fix handling of prerelease versions * Fix lint * Add 't' suffix to python-version output * Use distinct cache key for free threaded Python * Remove support for syntax like '3.14.0a1' * Clarify use of 't' suffix * Improve error message when trying to use free threaded Python versions before 3.13
* Support free threaded Python versions like '3.13t' Python wheels, pyenv, and a number of other tools use 't' in the Python version number to identify free threaded builds. For example, '3.13t', '3.14.0a1', '3.14t-dev'. This PR supports that syntax in `actions/setup-python`, strips the "t", and adds "-freethreading" to the architecture to select the correct Python version. See actions#771 * Add free threading to advanced usage documentation * Fix desugaring of `3.13.1t` and add test case. * Add freethreaded input and fix handling of prerelease versions * Fix lint * Add 't' suffix to python-version output * Use distinct cache key for free threaded Python * Remove support for syntax like '3.14.0a1' * Clarify use of 't' suffix * Improve error message when trying to use free threaded Python versions before 3.13
Description:
Please make Python 3.13 available, built with the
--disable-gilflag.Justification:
Thank you for actions/setup-python and especially for making it possible to test new pre-releases, and final releases within a day or so of their official release. (And see here how well GitHub Actions compares to other CI services :)
PEP 703 has been accepted to remove the GIL. The rollout is planned in three phases, and for success, it's extremely important to get community feedback and support to be able to move to the next phase.
Therefore it's also extremely important for the community to be able to test the "free-threaded" aka "nogil" builds of Python. This requires a separate build of 3.13 with the
--disable-gilflag enabled for the configure script (see the PEP and CPython CI).To achieve this, it would be very helpful if actions/setup-python also provided free-threaded builds for 3.13 (and later) to enable the community to try them out and give feedback, perhaps via
with: disable-gil: true.It's still a bit early for extension authors to start testing, but it would be great to have the testing infra ready for when the time comes.
Would this be possible?
Are you willing to submit a PR?
Yes.
The text was updated successfully, but these errors were encountered: