setup-python

setup-python copied to clipboard

Description

If one has on a job:

brew update
brew upgrade

the job fails with error:

 ==> Upgrading [email protected]
  3.10.8 -> 3.10.9 

==> Pouring [email protected]_sur.bottle.tar.gz
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink bin/2to3
Target /usr/local/bin/2to3
already exists. You may want to remove it:
  rm '/usr/local/bin/2to3'

To force the link and overwrite all conflicting files:
  brew link --overwrite [email protected]

To list all files that would be deleted:
  brew link --overwrite --dry-run [email protected]

Possible conflicting files are:
/usr/local/bin/2to3 -> /Library/Frameworks/Python.framework/Versions/3.11/bin/2to3
/usr/local/bin/idle3 -> /Library/Frameworks/Python.framework/Versions/3.11/bin/idle3
/usr/local/bin/pydoc3 -> /Library/Frameworks/Python.framework/Versions/3.11/bin/pydoc3
/usr/local/bin/python3 -> /Library/Frameworks/Python.framework/Versions/3.11/bin/python3
/usr/local/bin/python3-config -> /Library/Frameworks/Python.framework/Versions/3.11/bin/python3-config

This is similar to old issues:

• https://github.com/actions/runner-images/issues/2322
• https://github.com/actions/runner-images/issues/4020

Platforms affected

• [ ] Azure DevOps
• [ ] GitHub Actions - Standard Runners
• [ ] GitHub Actions - Larger Runners

Runner images affected

• [ ] Ubuntu 18.04
• [ ] Ubuntu 20.04
• [ ] Ubuntu 22.04
• [X] macOS 11
• [x] macOS 12
• [ ] Windows Server 2019
• [ ] Windows Server 2022

Image version and build link

Image Version: 20221215.1 Link: https://github.com/traversaro/github-actions-brew-update-upgrade-check/actions/runs/3742142787

Is it regression?

20221211.1

Expected behavior

The brew upgrade should exit fine.

Actual behavior

The brew upgrade fails with the error message in the top of the issue.

Repro steps

See https://github.com/traversaro/github-actions-brew-update-upgrade-check/blob/2fa847c627c643716ba10d681ea18c86c0b54dec/.github/workflows/brew-update.yml for a MWE .

Possibly related to https://github.com/actions/runner-images/issues/6459 .

Hi @traversaro , thank you, we will take a look.

I'm observing this as well

Also observed this here https://github.com/ryancurrah/lima-and-qemu/actions/runs/3745432855/jobs/6359863993 and here https://github.com/mook-as/lima-and-qemu/actions/runs/3743467832/jobs/6356414606.

EDIT:

I was able to get it working by removing the existing symlinks.

rm /usr/local/bin/2to3
rm /usr/local/bin/idle3
rm /usr/local/bin/pydoc3
rm /usr/local/bin/python3
rm /usr/local/bin/python3-config

It looks like it the universal python's package used in actions/setup-python is installing its symlinks to /usr/local, while I think it should not.

@marko-zivic-93 @dsame @dmitry-shibanov could you please take a look?

Got the same issue, and find out that something similar we had previously. Now it looks like:

  # homebrew fails to update python 3.9.1 to 3.9.1.1 due to unlinking failure
  rm /usr/local/bin/2to3 || true
  # homebrew fails to update python from 3.9 to 3.10 due to another unlinking failure
  rm /usr/local/bin/idle3 || true
  rm /usr/local/bin/pydoc3 || true
  rm /usr/local/bin/python3 || true
  rm /usr/local/bin/python3-config || true

It looks like it the universal python's package used in actions/setup-python is installing its symlinks to /usr/local, while I think it should not.

That is not the case for us and the OP:

/usr/local/bin/2to3 -> /Library/Frameworks/Python.framework/Versions/3.11/bin/2to3

There is seemingly a non-brew installed Python from somewhere else

@Flamefire the workflow does not use action/setup-python. It seems the links are created by the macos python package - i see them on the "almost" clean machine with the XCode installed.

@traversaro actully it is a normal behaviour. As you see from the log the installation continues normally with just a warning the links were not overwritten. The problem is brew upgrade exits with non-zero exit code and bash shell runs with set -e option. Thus the step signals the error condition despite brew upgrade is the very last command or not.

The easiest way to make the step to success is to add true after brew upgrade:

      - run: |
          brew update
          brew upgrade || true

Hello @fredroy, i see you forces the links by removing them manually in fact it is better to be done with

brew link --overwrite [email protected]

I'm also observing this behavior (just with running brew update and macOS 12): https://github.com/eMoflon/emoflon-ibex-eclipse-build/actions/runs/3764385410/jobs/6398766536

@dsame

@Flamefire the workflow does not use action/setup-python. It seems the links are created by the macos python package - i see them on the "almost" clean machine with the XCode installed.

Yes this is what I also observed and wrote in https://github.com/actions/setup-python/issues/577

As you see from the log the installation continues normally with just a warning the links were not overwritten. The problem is brew upgrade exits with non-zero exit code

We also see this when we install a package with brew (e.g. ccache) which requires Python and hence is automatically upgraded. Ignoring the exit code is not feasible in that case as it might hint to anything besides this issue.

i see you forces the links by removing them manually in fact it is better to be done with

brew link --overwrite [email protected]

This is also not feasible for us as the exact Python version required for a package to be installed is not known/may change.

Hence our workaround is to remove the symlinks on failure and retry: https://github.com/boostorg/boost-ci/blob/ac5ae7e901e49351d19de278cbf82ce8d2c44216/ci/setup_ccache.sh#L17-L24

@maxkratz

I'm also observing this behavior (just with running brew update and macOS 12): https://github.com/eMoflon/emoflon-ibex-eclipse-build/actions/runs/3764385410/jobs/6398766536

No, I also made this false assumption. The behavior is not triggered by the update (which just downloads meta information similar to apt-get update) but the following installation of a package: brew install p7zip coreutils grep wget curl (or brew upgrade but you don't use that here)

@maxkratz

I'm also observing this behavior (just with running brew update and macOS 12): https://github.com/eMoflon/emoflon-ibex-eclipse-build/actions/runs/3764385410/jobs/6398766536

No, I also made this false assumption. The behavior is not triggered by the update (which just downloads meta information similar to apt-get update) but the following installation of a package: brew install p7zip coreutils grep wget curl (or brew upgrade but you don't use that here)

Thank you for the clarification, you are right.

Any chance to have it fixed in the image? All was working before, I wouldn't want to use any workarounds.

@igagis the fix should be made in the actions/python-versions repo in first place, it is image - irrelevant.

@igagis the fix should be made in the actions/python-versions repo in first place, it is image - irrelevant.

This is not true. Many people with this issue do not use that action, the conflicting Python symlink targets e.g /Library/Frameworks/Python.framework/Versions/3.11/bin/2to3. See the workflow file from the original issue post: https://github.com/traversaro/github-actions-brew-update-upgrade-check/actions/runs/3742142787/workflow

@igagis the fix should be made in the actions/python-versions repo in first place, it is image - irrelevant.

I'm also not using this action, still see the issue

@Flamefire @igagis python-versions does not depend on setup-python, python-versions provides python which is later used in toolcache used by setup-python, so even if you do not invoke the action itself, you are still affected.

I'm not using either of setup-python, python-versions actions, should I still be affected?

@igagis yes, because toolcached python is installed during image creation process, no matter will anybody use it or not it is already a part of the image.

@mikhailkoliada Ok, do maintainers of actions/python-versions know that they need to fix the problem? The Issues section is disabled on their github repo.

@igagis That seems like a question for @MaksimZhukov

I've transferred the issue to the actions/setup-python repo as the most relevant place.

@mikhailkoliada Thank you, will the actions/python-versions team still need to be aware of the issue?

@david-engelmann both repos are maintained by the same people.

@mikhailkoliada perfect!

@mikhailkoliada @igagis In fact the links are created during the image generation

First they are created for osx nativ python 2.7

https://github.com/actions/runner-images/blob/main/images/macos/provision/core/python.sh#L9

Next they are forced to be overwritten with brew python 3.10

https://github.com/actions/runner-images/blob/main/images/macos/provision/core/python.sh#L23

Finally, during the adding toolcached Python, 3.11 is installed from .pkg and creates its own links

and they come to runner image:

2.7 soft linked to macos Library/Frameworks https://github.com/akv-demo/setup-python-test/actions/runs/3846511802/jobs/6551900903#step:2:22 3.10 soft linked to brew Cellar https://github.com/akv-demo/setup-python-test/actions/runs/3846511802/jobs/6551900903#step:2:23 3.11 soft linked to macos Library/Frameworks https://github.com/akv-demo/setup-python-test/actions/runs/3846511802/jobs/6551900903#step:2:24

Honestly i do not see an acceptable way to fix brew python 3.10 it besides (fix 1) removing the root cause and update the image with brew python 3.10.9 instead of current 3.10.8 https://github.com/akv-demo/setup-python-test/actions/runs/3847013097/jobs/6552968030#step:3:552 and 3.11.1 instead of 3.11.0 https://github.com/akv-demo/setup-python-test/actions/runs/3847013097/jobs/6552968030#step:3:140

Hi all,

I'm seeing this to in my GH actions:

https://github.com/SentryPeer/SentryPeer/actions/runs/3856144662/jobs/6571996740#step:5:630 on mac

Looks like issue was upgraded with Could not symlink bin/2to3-3.11

The issue is still there. Here is one more build log, if it helps somehow for analysis: https://github.com/cppfw/utki/actions/runs/3881378828/jobs/6740887891#step:4:297

The issue looks very serious and affecting a lot of users, since it is basically any brew install fails. Strange to see it is still not fixed and doesn't get any attention from maintainers :(