-
Notifications
You must be signed in to change notification settings - Fork 611
Fails to run on self hosted Windows runner if pip is not in PATH #1050
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
setup-python, by default, sets various cmake and pkg-config env vars, so that packages using cmake can be built. Since this might interfere with out package builds disable it. We only care about the Python executable itself, so use the action output to create the venv.
Hi @lazka, |
A workaround is to use "actions/cache" for caching instead, see msys2/msys2-autobuild@e9e823c |
Hi @lazka, Thank you for bringing up this issue! |
The action is failing internally and not my code, so I don't see how that is not a bug. I'm not using pip, the action is. |
Hi @lazka, As discussed earlier, the issue you are encountering is due to the update-environment: false flag. This option prevents the action from modifying environment variables such as PATH, which means that Python and pip are not automatically added to the PATH. As a result, commands like pip cannot run if they are not manually installed and configured in the self-hosted runner's environment. This is different from GitHub-hosted runners, where Python and pip are pre-installed, which is why this issue doesn’t occur there. To make this clearer, we have updated the error message in the action. The new error message is as follows:
This change aims to provide more clarity on the cause of the issue. If you decide to keep update-environment: false, you will need to ensure that pip and other necessary tools are explicitly available in the environment. We hope this clarifies the situation. Please let us know if you have any further questions or if there's anything else we can assist you with! ![]() |
Again, the error happens in the action itself and has nothing to do with my use of python or pip after the action. What you are suggesting is outside of my control as I can't control how the action is using pip/python. |
Hi @lazka, As mentioned earlier, we provide Python and pip as part of the action through setup-python. However, when update-environment: false is set, it prevents the action from modifying environment variables such as PATH. This means that pip and Python won’t be automatically added to the PATH, which is causing the issue you're encountering. |
As I pointed out in the initial post the action is already capable of finding its installed python/pip in other places of the code, so what you are saying is not correct. |
@gowridurgad Situations like these usually warrant that you put the LLM away in order to come up with a real response. Saves everybody’s time 😀 |
I'd suggest making a pull request to fix it, but past experience shows even those tend to languish for issues only affecting self-hosted runners. |
Hi @lazka, We understand your concern, and we’d like to clarify the issue based on how the setup-python action works, particularly in relation to pip installation. To give some context, the update-environment flag was introduced in PR #411 to provide users more control over whether or not the action should modify the system environment variables, like updating the PATH to include Python and pip. This was added because there were use cases where users didn't want the action to alter the global environment—particularly in scenarios where Python and pip are already managed externally. By setting update-environment: false, the action avoids modifying the system PATH, which explains why pip is not found in some cases As you correctly mentioned, the setup-python action is capable of finding its installed python and pip in some parts of the code, like in the install-pypy.ts file. The reason it works in install-pypy.ts is that the action explicitly installs pip through python -m ensurepip and then uses python -m pip to run commands. This is possible because it’s done in a controlled manner, and the Python executable is available at that point. However, in the case of pip-cache.ts, the action fails to find pip when update-environment: false is set. This is because, when update-environment: false is used, the action does not modify the system PATH. Therefore, both python and pip might not be available in the environment, and running something like pip cache dir will fail because pip is not in the PATH. The difference here is that pip-cache.ts tries to invoke pip directly from the shell, which requires pip to be globally available in the PATH. |
Yes, this is exactly what I wrote in the initial description of this issue. |
that's a very verbose description of the problem.
and that's a good description of the proposed fix for pip-cache.ts |
Description:
Downstream issue: msys2/msys2-autobuild@fe4bcd0#commitcomment-153600091
Running the following on a self-hosted Windows runner leads to:
error:
The problematic thing being "update-environment" (which we need to set, so it doesn't set cmake and pkg-config variables interfering with our builds. I don't mind the PATH, but setup-python only does all or nothing)
It looks like the cache code depends on pip being globally available, while it might not be:
setup-python/src/cache-distributions/pip-cache.ts
Lines 35 to 41 in 9e62be8
In other places this is handled correctly by explicitly going through the just installed python/pip, for example:
setup-python/src/install-pypy.ts
Lines 177 to 182 in 9e62be8
Action version:
actions/setup-python@v5
Platform:
Runner type:
Tools version:
3.13, but any really
Repro steps:
See above
Expected behavior:
The action to run
Actual behavior:
It errors out
The text was updated successfully, but these errors were encountered: