Python 3.14.0b1 full installer does not install `pip.exe`

[yosifkit]

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 : CommandNotFoundException

Alpha 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

[JelleZijlstra]

cc @zooba

[zooba]

Does python -m pip work?

Can you share your install logs (they'll be in %TEMP%)

[yosifkit]

Yes, python -m pip does 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]

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-pip is run during the pip phase, and pip responds with:

CAQuietExec64:  Looking in links: c:\Users\ContainerAdministrator\AppData\Local\Temp\tmpem3xdmw3
CAQuietExec64:  Requirement already satisfied: pip in c:\python\lib\site-packages (25.1.1)

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\pip and 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]

C:\Python is 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 add python -m to the pip --version test to get a successful run.

[zooba]

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 pip after 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 pip step to generate the script launchers, since those aren't redistributable and have to be generated after install.

[tianon]

Won't python -m pip install -f pip just pull the latest pip from pypi? Also, isn't -f "find links" ? Did you mean --force-reinstall? Wouldn't re-running ensurepip explicitly be a safer option that doesn't reinstall a new pip (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]

Won't python -m pip install -f pip just pull the latest pip from pypi? Also, isn't -f "find links" ? Did you mean --force-reinstall?

Ah yeah, it's not -f (it's -f in the install manager, which is all I've been thinking about for weeks, hence the confusion).

Wouldn't re-running ensurepip explicitly be a safer option that doesn't reinstall a new pip (potentially a new version)?

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.

(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)

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]

I used the same installer - without any command line modifications - to update from 3.14a7, and now py -3.14 -m pip says:

No module named pip.main; 'pip' is a package and cannot be directly executed

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.