Closed GlassOfWhiskey closed 1 year ago
You can verify yourself by exploring the workflow runs on the streamflow repository.
@GlassOfWhiskey I recommend that you first run this action before setting up Python. This seems to be a conflict between the Python version installed by action/setup-python
and the one from Homebrew. Ideally, action/setup-python
should find the one installed by Homebrew and use it.
Unfortunately I cannot remove HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK
as it can cause newly installed/upgrade "main packages" (docker, lima, colima, qemu) to use old versions of their dependencies, causing all sorts of weird issues.
@douglascamata I tried your suggestion in alpha-unito/streamflow#214 but unfortunately it didn't work. Even when running as the first action in a workflow, this action at the moment updates both Python 3.10 an Python 3.11, causing the conflict.
Hummm, I see. 🤔
I think I can remove some "old" workarounds that should allow us to set HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK=true
again without breaking things. I'll try it out.
Strongly considering to use nix
here to avoid having to deal with Homebrew's conflicts with system-wide packages.
Having a similar issue here, though setting the workaround as described above
- uses: douglascamata/setup-docker-macos-action@v1-alpha.9
env:
HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK: 1
Did not work for me at https://github.com/OWASP/wrongsecrets/pull/945/files with output at https://github.com/OWASP/wrongsecrets/actions/runs/6020963466/job/16333057066?pr=945 . Do you know what I can best do to still be able to use your awesome workflow @douglascamata ? Can you help me please?
@commjoen your issue now is very different though and it's a new issue we all will have. The dtc
link error happens even in my two macOS computers. Probably something's broken in Homebrew. 🤷
And it seems that I am correct: https://github.com/Homebrew/homebrew-core/issues/140677.
@commjoen your issue now is very different though and it's a new issue we all will have. The
dtc
link error happens even in my two macOS computers. Probably something's broken in Homebrew. 🤷
Thanks! anything i can do to fix my own issue?
@commjoen I don't know... I didn't even have time yet to fix the Python version issue. I think you can manually instal dtc
and do a brew link --force dtc
. Your action clearly downloaded a bottle that was already rebuilt, given the file name and sha256. We need to complain in the Homebrew issue.
To me this is one more reason to leave Homebrew. Broken bottle builds and other brew issues are the source of all problems this action has. 😓
I'm trying different approaches to avoid the conflicts altogether, give me some time.
I got a fix almost there in #19. Should be able to finish and merge it later today.
Hey folks, new release's out!
Tags v1-alpha
and v1-alpha.10
are updated.
Please try it out and let me know how it goes.
The action will now try to avoid upgrading/reinstalling QEMU if it's already present in the system. If you want to force a QEMU upgrade, use the new input for it (see https://github.com/douglascamata/setup-docker-macos-action?tab=readme-ov-file#inputsupgrade-qemu-defaults-to-false).
https://github.com/OWASP/wrongsecrets/pull/976 Seems to work
Thanks for the report, @commjoen. 👍
I'll give the other participants here some time to try it out and reply. Will close the issue if the feedback is positive or there's no more activity in between a week to ten days from now.
Version v1-alpha.10
solved Python conflict in StreamFlow. Thank you very much for your help
My pleasure, @GlassOfWhiskey. I'm closing this for now. Thanks for the report and testing. Hope this solution will last for a while (forever ideally). 🙇
Since Aug 25 2023, when I try to run this action I receive the following error
There is a conflict between upgraded Python versions related to the
/usr/local/bin/2to3
file. There is no difference in the environment (runner version, OS version, image provisioner, etc.) between the working and the broken runs. The only difference is that before Aug 25 the only indirect dependency loaded by Homebrew waskrb
Conversely, starting form Aug 25, the two Python versions started to appear, probably due to some update in the Homebrew package dependencies
As a workaround, I solved the issue by explicitly specifying
HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK
in the step's environment variables: