You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[BUG] setup-python fails across multiple Windows and action versions when caching is requested and newer pip outputs a deprecation warning (any really) #1034
UPD(17.02.2025): To anyone landing here from Google or hitting this bug otherwise
Tip
Here's the solution I landed on, not only because of just this bug, but I've also been wanting better cache control for quite a while, so I've wrapped what I've been copying and pasting for years into a more reusable component — a composite action that can sense whether it's safe to cache things based on the current runtime stability (ABI stability is computed based on the version being marked as final). Feel free to make use of it: https://github.com/re-actors/cache-python-deps.
P.S. The root cause of the bug is that setup-python threads any stderr from pip as a failure in any Windows runtimes. New pip started outputting a warning about a CLI flag being deprecated. That CLI flag is often being set via env vars like PIP_NO_PYTHON_VERSION_WARNING (meant to suppress another warning in the output). More explanation here: #1034 (comment).
Description:
I've been updating a few GHA configurations today and in the process saw the same error in several places. Interestingly, in some repos it fails in one workflow but works in another. I've been seeing this for the past few hours, but this is in repos I haven't touched in months, so the issue might've appeared earlier.
I've tried finding differences and similarities, but cannot say anything definitive.
Also, the action fails on both windows-2019 and windows-2022. It fails in matrixes that pass a variety of Python versions, starting with 3.9 and all the way to 3.13.
Another bit I noticed was that some of the jobs downloaded immutable actions, while others fetched from Git. But there's examples of both in failing/passing action invocations.
Failing job examples (there's more in the same workflow runs):
As you can see, there's successes and failures in the same repo, just different job definitions.
While writing this, I also noticed that the failing ones have some sort of file preparation before calling setup-python and caching args enabled. Worth checking out... I'll report back once I experiment some more.
Action version:
v5
Platform:
Ubuntu
macOS
Windows
Runner type:
Hosted
Self-hosted
Tools version:
🤷♂ seems to be any Python version and any windows image.
Repro steps:
Add a step with actions/setup-python@v5 into a windows job, set PIP_NO_PYTHON_VERSION_WARNING: 1 env var and add the cache: pip input.
Expected behavior:
It should succeed.
Actual behavior:
The action spits out Error: Could not get cache folder path for pip package manager, after the successful Installed versions output, and crashes the job.
UPD(17.02.2025): To anyone landing here from Google or hitting this bug otherwise
Tip
Here's the solution I landed on, not only because of just this bug, but I've also been wanting better cache control for quite a while, so I've wrapped what I've been copying and pasting for years into a more reusable component — a composite action that can sense whether it's safe to cache things based on the current runtime stability (ABI stability is computed based on the version being marked as final). Feel free to make use of it: https://github.com/re-actors/cache-python-deps.
The sample use would be
provided that it's invoked after
setup-pythonand after a sort of checkout (or similar). Integration example: aio-libs/frozenlist#622 / aio-libs/frozenlist#633.P.S. The root cause of the bug is that
setup-pythonthreads any stderr frompipas a failure in any Windows runtimes. New pip started outputting a warning about a CLI flag being deprecated. That CLI flag is often being set via env vars likePIP_NO_PYTHON_VERSION_WARNING(meant to suppress another warning in the output). More explanation here: #1034 (comment).Description:
I've been updating a few GHA configurations today and in the process saw the same error in several places. Interestingly, in some repos it fails in one workflow but works in another. I've been seeing this for the past few hours, but this is in repos I haven't touched in months, so the issue might've appeared earlier.
I've tried finding differences and similarities, but cannot say anything definitive.
Among the similarities, there's these:
Also, the action fails on both
windows-2019andwindows-2022. It fails in matrixes that pass a variety of Python versions, starting with 3.9 and all the way to 3.13.Another bit I noticed was that some of the jobs downloaded immutable actions, while others fetched from Git. But there's examples of both in failing/passing action invocations.
Failing job examples (there's more in the same workflow runs):
Success example:
As you can see, there's successes and failures in the same repo, just different job definitions.
While writing this, I also noticed that the failing ones have some sort of file preparation before calling
setup-pythonand caching args enabled. Worth checking out... I'll report back once I experiment some more.Action version:
v5
Platform:
Runner type:
Tools version:
🤷♂ seems to be any Python version and any windows image.
Repro steps:
Add a step with
actions/setup-python@v5into a windows job, setPIP_NO_PYTHON_VERSION_WARNING: 1env var and add thecache: pipinput.Expected behavior:
It should succeed.
Actual behavior:
The action spits out
Error: Could not get cache folder path for pip package manager, after the successfulInstalled versionsoutput, and crashes the job.