install pyyaml via apt - Githubissues

pyiron / actions

A centralized location for our GitHub actions

BSD 3-Clause "New" or "Revised" License

3 stars 0 forks source link

install pyyaml via apt #134

Open mbruns91 opened 1 month ago

mbruns91 commented 1 month ago

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

mbruns91 commented 1 month ago

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 commented 1 month ago

Maybe this issue will also be solved by the github devs over https://github.com/actions/runner-images/issues/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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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