setup-python failing for 3.9 on macos-latest
#981
Comments
|
Hello @abravalheri, |
|
Hi @abravalheri, The issue arises due to the behavior of the The version of To resolve this issue and ensure the setup process completes successfully, you can set the |
|
@abravalheri 👋, just a quick follow-up on the previous comment. Hope this helps clarify the situation. Please let us know if there are any concerns. Thanks! |
|
Thank you @priyagupta108 for having a look at this. The workaround you mention would be a bit problematic to implement for the following reason:
Do you have any suggestion on how to modify the workflow file and test matrix to conditionally set that environment variable for only that specific step (on This is currently how it looks like: ...
strategy:
# https://blog.jaraco.com/efficient-use-of-ci-resources/
matrix:
python:
- "3.9"
- "3.13"
platform:
- ubuntu-latest
- macos-latest
- windows-latest
include:
- python: "3.10"
platform: ubuntu-latest
- python: "3.11"
platform: ubuntu-latest
- python: "3.12"
platform: ubuntu-latest
- python: "3.14"
platform: ubuntu-latest
- python: pypy3.10
platform: ubuntu-latest
distutils: stdlib
- platform: ubuntu-latest
python: "3.10"
distutils: stdlib
# TODO: Re-evaluate the need for the following workaround
exclude:
- {python: "3.9", platform: "macos-latest"} # actions/setup-python#981
runs-on: ${{ matrix.platform }}
continue-on-error: ${{ matrix.python == '3.14' }}
env:
SETUPTOOLS_USE_DISTUTILS: ${{ matrix.distutils || 'local' }}
timeout-minutes: 75
steps:
- uses: actions/checkout@v4
- name: Setup Python
id: python-install
uses: actions/setup-python@v5
with:
python-version: ${{ matrix.python }}
allow-prereleases: true
...Do you know what was the recent change in behaviour that resulted in that? Was |
|
Hi @abravalheri 👋, - name: Setup Python
id: python-install
uses: actions/setup-python@v5
with:
python-version: ${{ matrix.python }}
allow-prereleases: true
env:
SETUPTOOLS_USE_DISTUTILS: ${{ matrix.platform == 'macos-latest' && matrix.python == '3.9' && 'stdlib' || matrix.distutils || 'local' }}This configuration ensures that:
The recent change in behavior is due to the removal of Python 3.9 on I hope this helps. Please let me know if you have any further questions. |
…version 75.7.0
Agriya Khetarpal (6):
Accept an `Iterable` at runtime for `Extension`
Add more tests to cover different iterables
Delegate to `os.fspath` for type checking
Fix typo
Add review suggestions around code comments
Use `TypeError` instead of `AssertionError`
Alex Waygood (1):
Bump Ruff to 0.8.0
Anders Theet (1):
Use minimum requirement for jaraco.functools
Anderson Bravalheri (1):
Workaround for actions/setup-python#981 (#4769)
Aohan Dang (1):
Fix issue with absolute path with Python 3.13 on Windows
Avasam (14):
use a real boolean (False) default for display_option_names generated attributes
Return real boolean from copy_file
Fix test_mkpath_exception_uncached
Remove link to jaraco/path#232
Bump mypy to 1.14, jaraco.path to 3.7.2
Run Ruff 0.8.0
UP031 manual fixes for Ruff 0.8.0
Make reinitialize_command's return type Generic when "command" argument is a Command
Coerce Distribution.script_args to list
Remove py38 compat modules
type `Distribution.get_command_obj` to not return `None` with `create=True`
ClassVar classvar mutables and tuple from typeshed
Fix test_build_ext.py on Python 3.9
Simplified typed assignments
Carson Lam (2):
Omit ruff config from distribution.
Include ruff.toml in sdist but not wheel.
Dimitri Papadopoulos (8):
Enforce ruff/pyupgrade rule UP030
Enforce ruff/pyupgrade rule UP031
A round of `ruff format` after `ruff check --fix`
Enforce ruff/pyupgrade rule UP032
A round of `ruff format` after `ruff check --fix`
Manual fixes after `ruff check --fix` runs
Manually remove more .format() calls
Manually remove more %-formatting
Jason R. Coombs (23):
Add a comment pointing to the motivation.
Trim the comment a bit.
👹 Feed the hobgoblins (delint).
Use alternate spelling for flavor attribute.
Only apply workaround on required Pythons.
Let pathlib resolve the flavor.
👹 Feed the hobgoblins (delint).
Remove UP036 exclusion.
Prefer the standard format for imports, even though it's unnecessarily repetitive.
👹 Feed the hobgoblins (delint).
Collapse startswith operations
👹 Feed the hobgoblins (delint).
Add news fragment.
Fix term reference in quickstart.
👹 Feed the hobgoblins (delint).
Extract a classmethod _make_out_path_exts suitable for isolated testing.
Re-write _make_relative to rely on pathlib for cross-platform and cross-python compatibility.
Move suppress_path_mangle to test_ccompiler to limit the scope.
Add tests and fix failure identified in the tests.
Refactor for simplicity.
Add news fragment.
Py_GIL_Disabled was handled previously.
Bump version: 75.6.0 → 75.7.0
Mathieu Dupuy (1):
correct 'namespace' term to 'namespace-package' in quickstart doc
Sam Gross (2):
Set `Py_GIL_DISABLED=1` for free threading on Windows
Link to setuptools issue
Sam James (2):
Use CFLAGS if set as-is, match CXXFLAGS behavior
Don't duplicate CFLAGS
Description:
The setup-python action started failing recently when installing Python 3.9 on the
macos-latest.Please note that the setup-python action is the second one to run, just after checkout (this was previously the case for 3.8, but not 3.9).
https://github.com/pypa/setuptools/actions/runs/12298183072/job/34321035714#step:3:49
Action version:
actions/setup-python@v5 - https://github.com/pypa/setuptools/actions/runs/12298183072/job/34321035714#step:3:1
Platform:
Runner type:
Tools version:
Python 3.9
Repro steps:
A description with steps to reproduce the issue. If your have a public example or repo to share, please provide the link.
https://github.com/pypa/setuptools/actions/runs/12298183072/job/34321035714#step:3:49
Expected behavior:
The setup-python action should successfully install Python 3.9 on
macos-latestindependently of the contents of the repository where the action is running.Actual behavior:
The setup-python action fails to install Python 3.9 on
macos-latestfor the setuptools repository.Please note that this problem has already been previously reported:
#860
The assessment in #860 (comment) that the problem is being caused by setuptools itself is not completely accurate.
While it is true that old versions of
setuptoolsdid expect every frame to contain a__file__attribute, this bug in the setuptools has been fixed around 3 years ago pypa/setuptools@137ab9d.What seems to be happening is that the host for the action has a pre-installed, very old version, and no longer supported version of setuptools, even before the action tries to run
ensurepip. Because that old version of setuptools is installed in the host,ensurepipfails.I believe that the best solution here is either:
setuptoolsinstalledsetuptoolsinstalledsetuptoolsdoes not get loaded when trying to installpipviaensurepip.python -m ensurepipwith some form of isolation flag (like-I)?Also note that the issue is happening on the setuptools repository specifically, which may mean the following:
cdinto/tmpbefore running the commands on setup-python? Or use some of the isolation flags when running Python scripts (e.g. -I)?Please see more information in #860.
The text was updated successfully, but these errors were encountered: