setup-python failing for 3.8 on macos-latest
#860
Comments
|
Update: even if I invert the order between |
|
Hello @abravalheri, Thank you for creating this issue and we will look into it :) |
|
macos-latest was recently changed from macos-13 to macos-14. macos-13 was x86_64, while macos-14 is arm64. This action fails on macos-latest from python 3.8, 3.9, and 3.10... but seems to be okay with python 3.11. Run actions/setup-python@v5
with:
python-version: 3.10
architecture: x64
check-latest: false
token: ***
update-environment: true
allow-prereleases: false
Installed versions
Version 3.10 was not found in the local cache
Version 3.10 is available for downloading
Download from "https://github.com/actions/python-versions/releases/download/3.10.14-9004012336/python-3.10.14-darwin-x64.tar.gz"
Extract downloaded archive
/usr/bin/tar xz -C /Users/runner/work/_temp/d6bc2d46-6597-4924-9815-3d930552f60f -f /Users/runner/work/_temp/dae42830-86a3-4ec2-a5a4-02a135b36224
Execute installation script
Check if Python hostedtoolcache folder exist...
Create Python 3.10.14 folder
Copy Python binaries to hostedtoolcache folder
Create additional symlinks (Required for the UsePythonVersion Azure Pipelines task and the setup-python GitHub Action)
Upgrading pip...
Error: dyld[8401]: Library not loaded: /usr/local/opt/gettext/lib/libintl.8.dylib
Referenced from: <09857011-94D0-3FBA-9F9D-9FCE0E7366FF> /Users/runner/hostedtoolcache/Python/3.
Error: 10.14/x64/bin/python3.10
Reason: tried: '/usr/local/opt/gettext/lib/libintl.8.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/gettext/lib/libintl.8.dylib' (no such file), '/usr/local/opt/gettext/lib/libintl.8.dylib' (no such file), '/usr/local/lib/libintl.8.dylib' (no such file), '/usr/lib/libintl.8.dylib' (no such file, not in dyld cache)
Error: ./setup.sh: line 53: 8401 Abort trap: 6 ./python -m ensurepip
Error: The process '/bin/bash' failed with exit code 134If you're relying on packages installed by homebrew or pre-installed to the runners, then the homebrew path is different on arm64 macs, verus the x86_64. The new path is |
|
Hi @ReenigneArcher, thank you very much for having a look on this. Yeah, I need this specifically on Python 3.8 (I did notice it work fine on 3.11).
I don't think I am. Even when You can see more details and the workflow file in pypa/setuptools#4343. |
Sorry, I didn't mean "you"... I meant the code within the action. I'm also experiencing the same issue as you, but wanted to share some information based other issues I've noticed with the new arm64 runners. I don't think github vetted the change to macos-14 (arm64) very well before making it the |
* tests: demonstrate #18 Fix 'setup.py' to prevent building 'okascore' module if 'PURE_PYTHON' is defined. Add 'py310-pure' environment to build / run tests with that env var set. Note that the new test fails under 'py310', but passes under 'py310-pure' * fix: use 'PyFloat_AsDouble' for upcasts - We know that the second element of each 'd2fitems' *should* be a float already (we store it, after all, in an IF BTree). - The upcast in the second change is safe, and more regular. * ci: bump checkout, setup-python action versions - Use released Python 3.12 * ci: work around GHA macos-latest messes: - actions/setup-python#850 - actions/setup-python#860 --------- Co-authored-by: Peter Wilkinson <[email protected]>
|
Hi @abravalheri👋, thank you for your report, Here are a couple of potential workarounds:
Hope this helps :) |
|
Hi @abravalheri, |
|
Hi @abravalheri, just checking in to see if there are any updates on this issue. Thank you! |
|
Hello @abravalheri, |
|
Hi @priyagupta108, I believe that this problem started to appear again for 3.9 in Please note that the assessment in #860 (comment) "Specifically, the _distutils_hack in setuptools assumes every frame has a file attribute" is lacking context. Indeed very old versions of setuptools used to assume that every frame has a What seems to be happening is that the host for the action has a pre-installed very old version of setuptools that is no longer supported, before trying to run ensurepip. Ideally the action should either uninstall this old version of There is not much else to be done in @priyagupta108 could you please re-open this issue? |
|
I submitted the issue again in #981. |
Description:
The
setup-pythonaction fails when installing Python 3.8 on themacos-latest.Please note that the
setup-pythonaction is the second one to run, just after checkout.https://github.com/pypa/setuptools/actions/runs/8982558570/job/24670435133?pr=4329#step:3:32
Action version:
actions/setup-python@v5- https://github.com/pypa/setuptools/actions/runs/8982558570/workflow?pr=4329#L73Platform:
Runner type:
Tools version:
Python 3.8
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/8982558570/job/24670435133?pr=4329#step:3:32
Expected behavior:
The
setup-pythonaction should successfully install Python 3.8 onmacos-latestindependently of the contents of the repository where the action is running.Actual behavior:
The
setup-pythonaction fails to install Python 3.8 onmacos-latestfor thesetuptoolsrepository.Please note that the issue is happening on the
setuptoolsrepository specifically, which may mean the following:setup-pythoncan be affected by which folders and files are present on the current working directory when the action runs...cdinto/tmpbefore running the commands onsetup-python? Or use some of the isolation flags when running Python scripts (e.g.-I)?Also note that the suggestions in #850 (comment) are not applicable. As far as I understand:
Upgrading setuptools: The suggestion to install an updated version of setuptools before the step that is failing is not feasible. The step that is failing is the installation of Python itself. Therefore, it's not possible to update anything when Python is not installed yet1.
Replacing setup.py with pyproject.toml: This suggestion also does not work and contains misleading and inaccurate information. The
pyproject.tomlis not more robust, it is just a different configuration format. Furthermore,setup.py,setup.cfg, andpyproject.tomlare not mutually exclusive; they can all exist at the same time and serve different purposes. This is exactly the case in the repository experiencing the issue.Footnotes
Unless the users should always assume that the Python is pre-installed on the worker and how this affects the available actions. Please let me know if there is any documentation about this. ↩
The text was updated successfully, but these errors were encountered: