Repository navigation
Python 3.14.0b1 full installer does not install pip.exe #133626
Description
Bug report
Bug description:
Using the python-3.14.0b1-amd64.exe installer no longer creates pip.exe when using include_pip=1 with PrependPath=1. Is this expected behavior? The python-3.14.0a7-amd64.exe installer worked fine. I thought it could be related to pep-0773, but that only deprecates the "full installer" which should still work as it has (until removed in 3.16).
Install command used:
Start-Process python-3.14.0b1-amd64.exe -Wait -NoNewWindow -PassThru \
-ArgumentList @( \
'/quiet', \
'InstallAllUsers=1', \
'TargetDir=C:\Python', \
'PrependPath=1', \
'Shortcuts=0', \
'Include_doc=0', \
'Include_pip=1', \
'Include_test=0' \
)Then trying to run python and pip:
$ # the installer updated PATH in the registry, refresh our local value
$ $env:PATH = [Environment]::GetEnvironmentVariable('PATH', [EnvironmentVariableTarget]::Machine);
$ python --version
Python 3.14.0b1
$ pip --version
pip : The term 'pip' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ pip --version
+ ~~~
+ CategoryInfo : ObjectNotFound: (pip:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundExceptionAlpha 7 was successful
$ # after an install with python-3.14.0a7-amd64.exe using the same CLI installer options as above and PATH refresh
$ python --version
Python 3.14.0a7
$ pip --version
pip 25.0.1 from C:\Python\Lib\site-packages\pip (python 3.14)CPython versions tested on:
3.14
Operating systems tested on:
Windows
Linked PRs
- gh-133626: Ensure the traditional Windows installed doesn't accidentally pick up site-packages #133693
- [3.14] gh-133626: Ensure the traditional Windows installer doesn't accidentally pick up site-packages (GH-133693) #133705
- [3.13] gh-133626: Ensure the traditional Windows installer doesn't accidentally pick up site-packages (GH-133693) #133707
Activity
JelleZijlstra commentedon May 8, 2025
cc @zooba
zooba commentedon May 8, 2025
Does
python -m pipwork?Can you share your install logs (they'll be in
%TEMP%)yosifkit commentedon May 8, 2025
Yes,
python -m pipdoes work.Here are all the log files: https://gist.github.com/yosifkit/69815779ee89ff585819df4bdc2d37fd (I was hoping they'd all display in a gist, but some of them still have to be downloaded 😞).
zooba commentedon May 8, 2025
Thanks. At a glance it looks fine, and nothing should have changed on the installer side.
The command
"C:\Python\python.exe" -I -m ensurepip -U --default-pipis run during the pip phase, and pip responds with:But normally this should be doing the install. So possibly what's happened is you're installing to an existing directory, pip is already installed, and so the install step just skips it.
Can you try deleting
C:\python\lib\site-packages\pipand its dist-info folder and then running a Repair for 3.14.0b1? If that doesn't work, then there may have been a change somewhere else that's causing it.yosifkit commentedon May 8, 2025
C:\Pythonis a non-existent folder at the start of the installer since this is done inside a Windows Docker container. Here is the Dockerfile, which I've done minimal local edits to keep the logs and addpython -mto thepip --versiontest to get a successful run.zooba commentedon May 8, 2025
Okay, I've checked the release build logs and I'm seeing some suggestion that the CI system may have installed pip into the wrong place. It may have been picked up by the installer build from there. If so, next beta should get fixed.
Until then your workaround is to add a
python -m pip install -f pipafter installing Python, which should recreate the script executable for you.When you switch to the new install manager (which you could do whenever you like now), you'd need to add an extra path to PATH to find its scripts, and will also need the
python -m pip install -f pipstep to generate the script launchers, since those aren't redistributable and have to be generated after install.tianon commentedon May 8, 2025
Won't
python -m pip install -f pipjust pull the latestpipfrom pypi? Also, isn't-f"find links" ? Did you mean--force-reinstall? Wouldn't re-runningensurepipexplicitly be a safer option that doesn't reinstall a newpip(potentially a new version)?(re the new install manager, it doesn't support all latest versions yet, right? in my testing, it appears to be missing at least 3.9.22, 3.10.17, 3.11.12, 3.13.3; also might be worth adding the same cosign/sigstore signatures to those artifacts as are available for other release builds)
zooba commentedon May 8, 2025
Ah yeah, it's not
-f(it's-fin the install manager, which is all I've been thinking about for weeks, hence the confusion).You'll need whatever the extra argument is to force it to reinstall. If you read up the thread, you'll see that ensurepip is what the installer runs, and it obviously didn't work.
All the ones that get binary releases, yes. We aren't starting to do builds for security-fix only releases. And new updates will get sigstore signatures - old ones requires convincing the release managers to go back manually and add them. Since Windows relies on Authenticode and sigstore is only for people browsing our FTP site in this case, it didn't seem urgent. But if you want to go make a fuss on a new issue, feel free.
pewscorner commentedon May 8, 2025
I used the same installer - without any command line modifications - to update from 3.14a7, and now
py -3.14 -m pipsays:How do I get around this? I'm not sure how it makes sense to use pip to install pip if pip is not present.
pythongh-133626: Ensure the traditional Windows installed doesn't acc…
zooba commentedon May 8, 2025
Probably find the
Lib\site-packagesfolder and delete thepipfolders, then either re-run the installer and Repair, or runpython -m ensurepip.pewscorner commentedon May 8, 2025
That worked (using repair), thanks!
gh-133626: Ensure the traditional Windows installer doesn't accidenta…
pythongh-133626: Ensure the traditional Windows installer doesn't acc…
gh-133626: Ensure the traditional Windows installer doesn't accidenta…
gh-133626: Ensure the traditional Windows installer doesn't accidenta…
stonebig commentedon May 11, 2025
remark: blurb package was also accidently included in b1
zooba commentedon May 11, 2025
Yeah, same reason. The docs build installed them both and they got collected when they shouldn't have. Seeing blurb in there is what told me what the problem was (though the fix is just to explicitly exclude the directory, rather than to fix the build order and leave the potential open).
pythongh-133626: Ensure the traditional Windows installer doesn't acc…
pythongh-133626: Ensure the traditional Windows installer doesn't acc…