Closed jvesely closed 1 month ago
I'm also seeing this (with python-version: 3.7
):
Run actions/setup-python@v5
with:
python-version: 3.7
cache: pip
check-latest: false
token: ***
update-environment: true
allow-prereleases: false
Installed versions
Version 3.7 was not found in the local cache
Error: The version '3.7' with architecture 'arm64' was not found for macOS 14.4.1.
The list of all available versions can be found here: https://raw.githubusercontent.com/actions/python-versions/main/versions-manifest.json
This is causing downstream breakage in some core Python dependencies: https://github.com/psf/cachecontrol/pull/333
3.7 is technically EOL, but many core Python tools (like pip
itself) have an compatibility policy that includes 3.7. As such, this should probably be supported on arm64 macOS runners until 3.7 is widely dropped (or at least from pip
and its dependencies, like cachecontrol
).
Hello @jvesely, Thank you for creating this issue and we will get back to you once we have some feedback on this :)
If I'm not mistaken, Python 3.7 has never been supported on macOS arm64 and upstream support in CPython has only been added for 3.8+ (in 3.8.10 for the 3.8 branch). It might be simpler to stick to macos-11/12/13 label if you want to test python<3.8
For me this looks like it's probably that the macos-latest
Github action runner appears to have switched to an M1 ARM mac, where at least last week macos-latest
was an x86 mac.
For me this looks like it's probably that the
macos-latest
Github action runner appears to have switched to an M1 ARM mac, where at least last weekmacos-latest
was an x86 mac.
This is the source of my observed breakage as well. It's perfectly fine for there to never be an arm64 build of Python 3.7, but it would be nice to have a clearer message to the effect of "this is happening because the runner is now an ARM runner, not because 3.7 has disappeared from x86 runners" 🙂
(Or potentially: could the ARM macOS runner use the x86 build? ARM macs have mature emulation support via Rosetta, so running the x86 3.7 build should work.)
(Or potentially: could the ARM macOS runner use the x86 build? ARM macs have mature emulation support via Rosetta, so running the x86 3.7 build should work.)
You can set architecture: x64
to use x64 python on aarch64 runners. I'd be nice if that was the default for setup-python
but you'll probably hit https://github.com/actions/setup-python/issues/855
GitHub Actions blog:
Over the next 12 weeks, jobs using the
macos-latest
runner label will migrate from macOS 12 (Monterey) to macOS 14 (Sonoma).
See workaround: https://github.com/actions/runner-images/issues/9770#issuecomment-2085623315
Does the CPython Core Team support Python 3.6 or 3.7 running on macOS ARM? I thought that they did not.
This is why I created the workaround:
@mikhailkoliada
No, the first version of Python to support Apple Silicon was 3.8. That just barely supported ARM, as it was hitting the 1.5 year support window for new features as Apple Silicon came out (which is also when official binaries stop being built). 3.9 has much better support. Older versions do not support Apple Silicon[^1].
[^1]: Apple briefly provided a patched 2.7 that they stopped shipping in macOS 12.3. And Xcode-command-line-tools Python 3.8 has their own patches.
3.7 is technically EOL, but many core Python tools (like pip itself) have an compatibility policy that includes 3.7.
The next release of pip (24.1b1) drops support for 3.7. Most other PyPA packages have dropped support for running on 3.7 (build, packaging, hatch, flit, setuptools, twine, wheel, pipx, setuptools_scm, cibuildwheel, installer, auditwheel, distutils). The only PyPA tools I'm aware of that still support running on 3.7 are pyproject-metadata (because I haven't dropped it yet 😳) and virtualenv.
I'd be nice if that was the default for setup-python
I would never want the default for Apple Silicon to be Intel emulation! It's nice if we have it as an option (if it worked), but trying to use it by default would cause issues (including potentially miscomputed binaries) as well as would be a terrible default in the future when Intel Apple machines are a memory.
@jvesely I think this issue can be closed as won’t do
.
@jvesely I think this issue can be closed as
won’t do
.
agreed. Thanks everyone!
Description: Using default python-architecture for python 3.7
Action version: v5
Platform:
Runner type:
Tools version: python 3.7
Repro steps:
setup-python python-version: 3.7
Expected behavior: python 3.7 installs and works
Actual behavior: