Repository navigation
pip is broken after downgrade on Windows pypy-3.11 #1348
Description
Description:
When using the setup-python action with pypy-3.11 on Windows, installing a version of pip older than the version pre-installed by setup-python results in a completely broken pip.
Here is an example workflow run that demonstrates the issue:
https://github.com/bashonly/setup-python-pypy-pip-bug/actions/runs/30870303776
Action version:
reproducible on v7.0.0, v6.3.0, v6.2.0, possibly older versions
Platform:
- Windows
(not reproducible on Ubuntu)
Runner type:
- Hosted
Tools version:
pypy-3.11
Repro steps:
- Create a GHA workflow with a job that runs on
windows-latest - Add a step that uses
actions/setup-pythonwithpython-version: pypy-3.11 - Add a step that downgrades pip, e.g.
python -m pip install "pip==26.1.2" - Add a step that attempts to use the downgraded pip, e.g.
python -m pip install requests - Run the workflow
Here is a reproducer workflow:
demo.yml
name: PyPy pip bug MRE
on:
workflow_dispatch:
permissions:
contents: read
jobs:
demonstrate:
name: Demonstrate PyPy pip issue
permissions:
contents: read
runs-on: windows-latest
steps:
- uses: actions/setup-python@ece7cb06caefa5fff74198d8649806c4678c61a1 # v6.3.0
with:
python-version: pypy-3.11
- name: Downgrade pip
run: |
python -m pip install "pip==26.1.2"
- name: Use pip
run: |
python -m pip install -U requestsExpected behavior:
The downgraded pip should not be broken.
Actual behavior:
The downgraded pip immediately raises an ImportError upon execution.
Analysis:
The root cause seems to be setup-python unconditionally upgrading pip to the latest version using the --ignore-installed pip flag:
setup-python/src/install-pypy.ts
Lines 175 to 183 in 5fda3b9
| async function installPip(pythonLocation: string) { | |
| core.info('Installing and updating pip'); | |
| const pythonBinary = path.join(pythonLocation, 'python'); | |
| await exec.exec(`${pythonBinary} -m ensurepip`); | |
| await exec.exec( | |
| `${pythonLocation}/python -m pip install --ignore-installed pip` | |
| ); | |
| } |
The --ignore-installed option tells pip not to uninstall any existing version of the package, but instead to merely install on top of any existing packages. This seems to cause some confusion as to what version is actually installed, as evidenced by the setup-python output from the example workflow run log:
setup-python log snippet
Installing and updating pip
C:\hostedtoolcache\windows\PyPy\3.11.15\x64\python.exe -m ensurepip
Looking in links: c:\Users\RUNNER~1\AppData\Local\Temp\tmpz17a6bza
Processing c:\users\runner~1\appdata\local\temp\tmpz17a6bza\setuptools-79.0.1-py3-none-any.whl
Processing c:\users\runner~1\appdata\local\temp\tmpz17a6bza\pip-24.0-py3-none-any.whl
Installing collected packages: setuptools, pip
WARNING: The scripts pip3.11.exe and pip3.exe are installed in 'C:\hostedtoolcache\windows\PyPy\3.11.15\x64\Scripts' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
Successfully installed pip-24.0 setuptools-79.0.1
C:\hostedtoolcache\windows\PyPy\3.11.15\x64\python.exe -m pip install --ignore-installed pip
Collecting pip
Downloading pip-26.2-py3-none-any.whl.metadata (4.6 kB)
Downloading pip-26.2-py3-none-any.whl (1.8 MB)
---------------------------------------- 1.8/1.8 MB 38.4 MB/s eta 0:00:00
Installing collected packages: pip
WARNING: The scripts pip.exe, pip3.11.exe and pip3.exe are installed in 'C:\hostedtoolcache\windows\PyPy\3.11.15\x64\Scripts' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
Successfully installed pip-24.0
During the upgrade, pip knows it's installing version 26.2, but after installation is complete it reports that version 24.0 is installed. (pip 24.0 is the version that is bootstrapped with ensurepip.)
If we look at the "Use pip" step from example workflow run log, we can see that our attempt to use pip 26.1.2 errors and emits the following traceback:
File "C:\hostedtoolcache\windows\PyPy\3.11.15\x64\Lib\site-packages\pip\_internal\cli\main_parser.py", line 11, in <module>
from pip._internal.build_env import get_runnable_pip
File "C:\hostedtoolcache\windows\PyPy\3.11.15\x64\Lib\site-packages\pip\_internal\build_env\__init__.py", line 8, in <module>
from pip._internal.build_env.installer import (
File "C:\hostedtoolcache\windows\PyPy\3.11.15\x64\Lib\site-packages\pip\_internal\build_env\installer.py", line 22, in <module>
from pip._internal.utils.misc import get_runnable_pip
ImportError: cannot import name 'get_runnable_pip' from 'pip._internal.utils.misc' (C:\hostedtoolcache\windows\PyPy\3.11.15\x64\Lib\site-packages\pip\_internal\utils\misc.py)
Error: Process completed with exit code 1.
_internal\build_env\__init__.py does not exist in pip<26.2. This suggests that the file was left behind from the pip version 26.2 that was installed prior to the downgrade (possibly because the package metadata used to uninstall 26.2 actually belonged to version 24.0). It tries to import get_runnable_pip from pip._internal.utils.misc, but the function wasn't moved into that module until pip version 26.2, so the ImportError is raised.
Activity
v-jitenderpalsingh commentedon Aug 4, 2026
Hello @bashonly,
Thank you for creating this issue. We will investigate it and provide feedback as soon as we have some updates.
[ci] Fix broken Windows PyPy tests (#17347)
v-jitenderpalsingh commentedon Aug 12, 2026
Hi @bashonly, thanks for the detailed analysis.
We investigated the issue and found that pip is being overwritten, which can leave the installation in an inconsistent state.
Please try one of the following workarounds:
Please let us know whether either workaround resolves the issue for your use case or if you need any further assistance. Thank you!
Merge upstream master (yt-dlp/yt-dlp) into fork (#1)
v-jitenderpalsingh commentedon Aug 24, 2026
Hello @bashonly, just a gentle follow-up on this issue. If you have any updates or need further assistance, please let us know.
bashonly commentedon Aug 24, 2026
I found a workaround, but shouldn't this still be properly fixed? I mean, that's why I submitted the bug report.
If this behavior isn't corrected, it could lead to PyPy's pip being completely broken out-of-the-box in a future release. Isn't that something that should be prevented?
v-jitenderpalsingh commentedon Aug 28, 2026
Hello @bashonly,
Thank you for following up. Your concerns are noted and being considered.
Since the current behavior has existed for a long time and may be relied upon by existing workflows, we are carefully evaluating the compatibility impact of potential changes.
We will also keep this issue open for further community engagement to help us better understand existing use cases.
Thank you again for the detailed report.
chore: incorporate the changes from upstream
ci: fix pip install on Windows PyPy