PEP 703: actions/setup-python python3.13t builds with --disable-gil

[hugovk]

Description:

Please make Python 3.13 available, built with the --disable-gil flag.

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-gil flag 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.

[dmitry-shibanov]

Hello @hugovk. Thank you for your feature request. We'll take a look on it.

[hugovk]

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!

[ngoldbaum]

@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 setup-python would make doing so much more straightforward for many projects.

[willingc]

@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?

[tonybaloney]

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.

[mayeut]

I had a first look at how it could be implemented given the current state of things in actions:

• manifest files generation seems compatible with the addition of a new field to account for different variants of a given tool.
• however toolcache does expect the manifest to follow a specific semantic so it would require an update if going with a new field for different variants of a given tool.

That being said, the arch field of the manifest is just a string so it could be used to provide variants (e.g. x64-nogil).

This is probably not user friendly so while the actions/python-versions repo could use such a hack, the actions/setup-pyton might want to provide an option - as proposed in the description - and leave the hack as an internal detail that could be changed if manifest generation/consumption gets updated.

I'm willing to submit Pull Requests but need some guidance regarding what's acceptable from the maintainers first.

cc @dmitry-shibanov, @HarithaVattikuti, @aparnajyothi-y

[EwoutH]

I’m curious, with Python 3.13 now being in the release candidate phase, is anyone still working on this or discussing it?

[jimkring]

I'm also curious if anyone has worked on this yet. For Windows, at least, the python-version release installer for Windows seem to already have an installer capable of installing the free-threaded binary. Just need to update the setup.ps1 powershell script (that lives inside the zip) to pass the Include_freethreaded=1 option to the installer (and then maybe remove/rename the installed GIL binary python.exe with the NOGIL binary python3.13t.exe that is installed next to it).

e.g. here is how I've installed the 3.13rc1 nogil binary with a powershell script:

$pythonInstallerUrl = "https://www.python.org/ftp/python/3.13.0/python-3.13.0rc1-amd64.exe"
Invoke-WebRequest $pythonInstallerUrl -OutFile setup-python.exe
Start-Process "setup-python.exe" -argumentlist "/quiet PrependPath=1 TargetDir=C:\Python313 Include_freethreaded=1" -wait
Rename-Item -Path "C:\Python313\python.exe" -NewName "pythonw3.13.exe"
Rename-Item -Path "C:\Python313\python3.13t.exe" -NewName "python.exe"

[ssbarnea]

Maybe it would be a good idea to add python3.13t to the tile of this issue. I do expect to be able to accept 3.13t as a valid version once this is done.

[XuehaiPan]

As a workaround, I'm currently using pyenv to test my C extension with Python built with --pydebug --disable-gil.

https://github.com/metaopt/optree/blob/v0.13.0/.github/workflows/tests-with-pydebug.yml#L33-L125

[hugovk]

Python 3.13.0 final has now been released: 🚀

https://discuss.python.org/t/python-3-13-0-final-has-been-released/66972

Maybe it would be a good idea to add python3.13t to the tile of this issue.

Done.

[ngoldbaum]

There's also the deadsnakes github action: https://py-free-threading.github.io/ci/

[henryiii]

This should work for now (and until 3.13 is in the runner images, is much faster too):

- uses: astral-sh/setup-uv@v3
- run: uv python install 3.13t
- run: uv venv --python 3.13t
- run: ./venv/bin/python ...

cibuildwheel also supports free-threaded Python if you are making wheels, there's a flag to enable it there.

[ngoldbaum]

@henryiii sorry, did you typo and perhaps meant - uses: astral-sh/setup-uv@v3?

Also I think it might be easier to just activate the venv with e.g. run: source ./venv/bin/activate

[henryiii]

Thanks, fixed! And environment modification is not persisted between steps in GHA.

[ngoldbaum]

I ended up going with:

    - uses: astral-sh/setup-uv@v3
    - run: |
	uv python install 3.13t
        uv venv --python 3.13t
        . .venv/bin/activate
        echo PATH=$PATH >> $GITHUB_ENV

Which installs a free-threaded python, runs the activate script, then makes sure the PATH set by the script gets persisted to later steps. That should work out to the same thing as using explicit paths, it just would have been annoying to do that given python is getting used via shebangs in the NumPy CI.

[zx80]

After reading the thread and noticing that it is still open, I understand that it is not available yet. Ok, maybe later…

The advices about using other python images seem fine, but I fail to see how it can be integrated seamlessly into a python-version matrix used alongside actions/setup-python, and I'm not motivated enough to create a new CI script. Any hint?

[hugovk]

@zx80 See some of the linked PRs. For example: python-pillow/Pillow#8200

An lightly-edited version:

jobs:
  build:
    strategy:
      fail-fast: false
      matrix:
        os: [ "macos-14", "ubuntu-latest" ]
        python-version: [ "pypy3.10", "3.13", "3.12", "3.11", "3.10", "3.9" ]
        include:
        # Free-threaded
        - { os: "ubuntu-latest", python-version: "3.13-dev", disable-gil: true }

    runs-on: ${{ matrix.os }}
    name: ${{ matrix.os }} Python ${{ matrix.python-version }} ${{ matrix.disable-gil && 'free-threaded' || '' }}

    steps:
    - uses: actions/checkout@v4

    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v5
      if: "${{ !matrix.disable-gil }}"
      with:
        python-version: ${{ matrix.python-version }}
        allow-prereleases: true
        cache: pip
        cache-dependency-path: "pyproject.toml"

    - name: Set up Python ${{ matrix.python-version }} (free-threaded)
      uses: deadsnakes/[email protected]
      if: "${{ matrix.disable-gil }}"
      with:
        python-version: ${{ matrix.python-version }}
        nogil: ${{ matrix.disable-gil }}

    - name: Set PYTHON_GIL
      if: "${{ matrix.disable-gil }}"
      run: |
        echo "PYTHON_GIL=0" >> $GITHUB_ENV

[aparnajyothi-y]

Hello Everyone, Thank you for your feature request and your patience. We're pleased to inform you that this request has been prioritized for the next quarter based on our current priorities set by the product team.

We will keep you updated with any progress and appreciate your continued support!

[hugovk]

@aparnajyothi-y Thank you, it's good to hear from the GitHub team ahead of this issue's one-year birthday on Saturday :) 🎂

It would be great if you can already do something about it this quarter, and the good news is there is already an open PR to implement this, and by the author of PEP 703. Please see PR #973.