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

python3.7-arm64 is not available #856

Closed
2 of 5 tasks
jvesely opened this issue Apr 26, 2024 · 12 comments
Closed
2 of 5 tasks

python3.7-arm64 is not available #856

jvesely opened this issue Apr 26, 2024 · 12 comments
Assignees
Labels
bug Something isn't working

Comments

@jvesely
Copy link

jvesely commented Apr 26, 2024

Description:
Using default python-architecture for python 3.7

Action version:
v5

Platform:

  • Ubuntu
  • macOS
  • Windows

Runner type:

  • Hosted
  • Self-hosted

Tools version:
python 3.7

Repro steps:
setup-python python-version: 3.7

Expected behavior:
python 3.7 installs and works

Actual behavior:

Run actions/setup-python@v5
  with:
    python-version: 3.7.16
    check-latest: false
    token: ***
    update-environment: true
    allow-prereleases: false
Installed versions
  Version 3.7.16 was not found in the local cache
  Error: The version '3.7.16' 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
@jvesely jvesely added bug Something isn't working needs triage labels Apr 26, 2024
jvesely added a commit to jvesely/PsyNeuLink that referenced this issue Apr 26, 2024
Except for python3.7 on macos.
x64 builds are broken on macos-14 images[0],
but python3.7 does not provide arm64 image[1]

[0] actions/setup-python#855
[1] actions/setup-python#856

Signed-off-by: Jan Vesely <[email protected]>
jvesely added a commit to jvesely/PsyNeuLink that referenced this issue Apr 26, 2024
Restrict python3.7 macos jobs to macos-13.
x64 builds are broken on macos-14 images[0],
but python3.7 does not provide arm64 image[1]

[0] actions/setup-python#855
[1] actions/setup-python#856

Signed-off-by: Jan Vesely <[email protected]>
jvesely added a commit to jvesely/PsyNeuLink that referenced this issue Apr 26, 2024
In practise it means x64 for linux and windows and arm64 for macos.

Restrict python3.7 macos jobs to macos-13.
x64 builds are broken on macos-14 images[0],
but python3.7 does not provide arm64 image[1]

[0] actions/setup-python#855
[1] actions/setup-python#856

Signed-off-by: Jan Vesely <[email protected]>
jvesely added a commit to jvesely/PsyNeuLink that referenced this issue Apr 26, 2024
…d docs

In practise it means x64 for linux and windows and arm64 for macos.

Restrict python3.7 macos jobs to macos-13.
x64 builds are broken on macos-14 images[0],
but python3.7 does not provide arm64 image[1]

[0] actions/setup-python#855
[1] actions/setup-python#856

Signed-off-by: Jan Vesely <[email protected]>
@shawnbrown
Copy link

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

@woodruffw
Copy link

This is causing downstream breakage in some core Python dependencies: psf/cachecontrol#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).

@aparnajyothi-y
Copy link
Contributor

Hello @jvesely, Thank you for creating this issue and we will get back to you once we have some feedback on this :)

@mayeut
Copy link
Contributor

mayeut commented Apr 29, 2024

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

xref actions/runner-images#9770

@mikedh
Copy link

mikedh commented Apr 29, 2024

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.

@woodruffw
Copy link

woodruffw commented Apr 29, 2024

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.

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

@jvesely
Copy link
Author

jvesely commented Apr 29, 2024

(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 #855

@cclauss
Copy link
Contributor

cclauss commented Apr 30, 2024

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

https://github.blog/changelog/2024-04-01-macos-14-sonoma-is-generally-available-and-the-latest-macos-runner-image

See workaround: actions/runner-images#9770 (comment)

@henryiii
Copy link

henryiii commented May 9, 2024

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

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.

Footnotes

  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.

@cclauss
Copy link
Contributor

cclauss commented May 9, 2024

@jvesely I think this issue can be closed as won’t do.

danibene added a commit to danibene/tempbeat that referenced this issue May 12, 2024
@jvesely
Copy link
Author

jvesely commented May 29, 2024

@jvesely I think this issue can be closed as won’t do.

agreed. Thanks everyone!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

8 participants