Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Tracked by #229
hugovk opened this issue Nov 23, 2023 · 21 comments
Open
Tracked by #229

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

hugovk opened this issue Nov 23, 2023 · 21 comments
Assignees
Labels
feature request New feature or request to improve the current logic

Comments

@hugovk
Copy link
Contributor

hugovk commented Nov 23, 2023

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.

@hugovk hugovk added feature request New feature or request to improve the current logic needs triage labels Nov 23, 2023
@dmitry-shibanov
Copy link
Contributor

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

@hugovk
Copy link
Contributor Author

hugovk commented Apr 11, 2024

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
Copy link

@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
Copy link

@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
Copy link

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
Copy link
Contributor

mayeut commented May 20, 2024

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
Copy link

EwoutH commented Aug 10, 2024

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

@jimkring
Copy link

jimkring commented Aug 13, 2024

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"

dimaqq added a commit to canonical/operator that referenced this issue Aug 19, 2024
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)
@ssbarnea
Copy link

ssbarnea commented Oct 8, 2024

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
Copy link

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 hugovk changed the title PEP 703: actions/setup-python builds with --disable-gil PEP 703: actions/setup-python python3.13t builds with --disable-gil Oct 8, 2024
@hugovk
Copy link
Contributor Author

hugovk commented Oct 8, 2024

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
Copy link

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

@henryiii
Copy link

henryiii commented Oct 16, 2024

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
Copy link

@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
Copy link

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

@ngoldbaum
Copy link

ngoldbaum commented Oct 16, 2024

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
Copy link

zx80 commented Oct 27, 2024

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
Copy link
Contributor Author

hugovk commented Oct 27, 2024

@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

colesbury added a commit to colesbury/setup-python that referenced this issue Oct 29, 2024
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
@aparnajyothi-y
Copy link
Contributor

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
Copy link
Contributor Author

hugovk commented Nov 21, 2024

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

@makukha
Copy link

makukha commented Dec 7, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request to improve the current logic
Projects
None yet
Development

No branches or pull requests