install pyyaml via apt

[mbruns91]

See title. Somehow, the runner-os complains when trying to use pip install pyyaml. So I replaced this by apt install python3-yaml. See also here

[liamhuber]

Rather not; per this comment this would break the action for windows, and the problem seems to be an upstream issue -- better that users avoid specifying the problematic runner. I recommend to close this PR.

[mbruns91]

I'm totally on your page to not break this action for non-ubuntu runners. But I think it's a bit unsatisfactory to implicitly pin the upper bound of the OS version.

We could, for example, ether

• have a look how the pipx command can be used on windows and MacOS runner-images; this is an alterative way to install pip packages without messing with system-python by using a venv.
• install pyyaml (and other pip-installed packages) - if possible - via the respective package manager: APT (apt) for ubuntu, homebrew (brew) for MacOS and Chocolatey (choco) for windows.
  (have a look here)

I'm on mobile right now and I don't think I'll come back to my PC before tomorrow morning. But I'd be happy to work on this, if you agree that this should be implemented in a more flexible way.

Maybe this issue will also be solved by the github devs over here.
I changed this PR to draft for now.

[liamhuber]

Maybe this issue will also be solved by the github devs over actions/runner-images#10781.
I changed this PR to draft for now.

Yes, this is the crux of my argument -- it's not our fault, and if we wait a bit it will go away. I think pip not working is a full-on bug, and I'm not aware of a fundamental reason to stop using it.

I'm totally on your page to not break this action for non-ubuntu runners. But I think it's a bit unsatisfactory to implicitly pin the upper bound of the OS version.

Instead of "fixing" it in the action here, we could alternatively make a (temporary) fix in the reusable workflow itself where we explicitly change the default runner from "ubuntu-latest" to a pinned older ubuntu runner.

[mbruns91]

When seeing their discussion, I'm not so sure they will fix it soon.
Alternatively, to avoid work downstream now and also when the issue might get fixed, we could use ubuntu-22.04 as default. Otherwise some of our workflows fail by default and also it's super easy to revert this to ubuntu-latest if required.

[mbruns91]

Another solution would be to use

pip install <package> --break-system-packages

.
While this is generally considered bad practice, I think it's okay for runners, as they are killed quickly anyway.

[liamhuber]

My top preference would be to leverage the existing runner kwarg downstream, I can also handle updating the default.