This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Windows installer for 2.7.13 doesn't install pip when installing to C:\Program Files
Type: Stage: resolved
Components: Installation, Windows Versions: Python 2.7
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: KevKeating, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2017-06-21 17:59 by KevKeating, last changed 2022-04-11 14:58 by admin. This issue is now closed.

File name Uploaded Description Edit
log.txt KevKeating, 2017-06-22 14:20
Messages (10)
msg296571 - (view) Author: Kevin Keating (KevKeating) Date: 2017-06-21 17:59
If I use the Python 64-bit 2.7.13 Windows installer and install to C:\Program Files\Python27, then the Scripts folder doesn't get created and pip doesn't get installed.  If I uninstall Python and reinstall it to C:\Python27, C:\Programs\Python27, or "C:\Path with spaces\Python27", then the Scripts folder is created and pip works correctly.  If I install Python 2.7.12 using or Python 3.6.1 using, then I don't experience this issue.  This issue does happen if I install to C:\PROGRA~1\Python27, which is the 8.3 filename equivalent of C:\Program Files\Python27.  I've seen this on a handful of Windows 10 computers so far.  I haven't tried other versions of Windows or the 32-bit installers.

Steps to reproduce:
- Download the Python installer from and run it.
- Select "Install for all users" and click Next.
- Enter C:\Program Files\Python27 as the installation folder and click Next.
- Click on "Register Extensions" and select "Entire feature will be unavailable".  (I don't know if this step is required, but it's what I've been doing to test.)  Click Next.
- Click Yes at the UAC prompt.
- Wait for installation to finish.

Expected results:
The "C:\Program Files\Python27\Scripts" and "C:\Program Files\Python27\Lib\site-packages\pip" folders should get created during the installation.

Actual results:
Neither of the folders exist.
msg296575 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-06-21 19:26
I wonder if the custom action to run _ensurepip isn't running as admin... that would be the only thing I can think of.

Can you try running the installer with:

  msiexec /l*vx log.txt /i path_to.msi

Then attach the generated log.txt file? We might be able to see what's happening better with that.
msg296631 - (view) Author: Kevin Keating (KevKeating) Date: 2017-06-22 14:20
Here's the log file.  I'm assuming that the relevant bit starts at around line 18663:

CAQuietExec:  Collecting setuptools
CAQuietExec:  Collecting pip
CAQuietExec:  Installing collected packages: setuptools, pip
CAQuietExec:  Exception:
CAQuietExec:  Traceback (most recent call last):
CAQuietExec:    File "c:\users\keating\appdata\local\temp\tmpcvofqv\pip-9.0.1-py2.py3-none-any.whl\pip\", line 215, in main
CAQuietExec:      status =, args)
CAQuietExec:    File "c:\users\keating\appdata\local\temp\tmpcvofqv\pip-9.0.1-py2.py3-none-any.whl\pip\commands\", line 342, in run
CAQuietExec:      prefix=options.prefix_path,
CAQuietExec:    File "c:\users\keating\appdata\local\temp\tmpcvofqv\pip-9.0.1-py2.py3-none-any.whl\pip\req\", line 784, in install
CAQuietExec:      **kwargs
CAQuietExec:    File "c:\users\keating\appdata\local\temp\tmpcvofqv\pip-9.0.1-py2.py3-none-any.whl\pip\req\", line 851, in install
CAQuietExec:      self.move_wheel_files(self.source_dir, root=root, prefix=prefix)
CAQuietExec:    File "c:\users\keating\appdata\local\temp\tmpcvofqv\pip-9.0.1-py2.py3-none-any.whl\pip\req\", line 1064, in move_wheel_files
CAQuietExec:      isolated=self.isolated,
CAQuietExec:    File "c:\users\keating\appdata\local\temp\tmpcvofqv\pip-9.0.1-py2.py3-none-any.whl\pip\", line 345, in move_wheel_files
CAQuietExec:      clobber(source, lib_dir, True)
CAQuietExec:    File "c:\users\keating\appdata\local\temp\tmpcvofqv\pip-9.0.1-py2.py3-none-any.whl\pip\", line 323, in clobber
CAQuietExec:      shutil.copyfile(srcfile, destfile)
CAQuietExec:    File "C:\Program Files\Python27\lib\", line 83, in copyfile
CAQuietExec:      with open(dst, 'wb') as fdst:
CAQuietExec:  IOError:  Permission denied: 'C:\\Program Files\\Python27\\Lib\\site-packages\\'
msg296632 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2017-06-22 14:39
Presumably you overrode the default location of C:\Python27 in favour
of C:\Program Files?

I'm not sure we've ever supported installing Python 2.7 in "Program
Files", precisely because of the security constraints on that
directory (plus the fact that a long time ago, directories with spaces
in them were badly handled, but that problem should no longer exist).
msg296634 - (view) Author: Kevin Keating (KevKeating) Date: 2017-06-22 14:52
Yeah, I only run into this problem if I install Python 2.7.13 into C:\Program Files\Python27.  If I install Python 2.7.12 or 3.6.1 to the same location, then everything works fine.  I can successfully install Python 2.7.13 to C:\Python27, C:\Programs\Python27, or "C:\Path with spaces\Python27".
msg296636 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-06-22 15:16
The relevant lines are just above the ones you posted, but I can't view the attachment from my phone so I'll have to look later.

Seems like the custom action is running as the original user and not admin. This should just be a flag on the command, though since we're building the msi without any tools it'll take some effort to figure that out.

Personally I'd rather say it's not supported. Install without pip and then add it later. But if someone comes with a patch and test results I'll happily merge it.
msg296638 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2017-06-22 15:40
Issue 27888 switched to using WiX CAQuietExec task to hide the console, but it also changed the action flags to no longer include msidbCustomActionTypeNoImpersonate (2048). Without this flag, the installer impersonates the user for these custom actions: UpdatePip, RemovePip, CompilePyc, CompilePyo, CompileGrammar. 

As a workaround, run the .msi from an elevated command prompt. In this case, I also recommend enabling the option to pre-compile the standard library.
msg296640 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2017-06-22 15:48
Note that even if you do get this working, you'll still need to run
pip from an elevated prompt every time you want to use it to install
new packages (or use --user).
msg296642 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2017-06-22 16:12
You can still create and use virtual environments (virtualenv) without requiring administrator access.
msg296643 - (view) Author: Kevin Keating (KevKeating) Date: 2017-06-22 16:24
Running the msi from an elevated command prompt worked.  Thanks!
Date User Action Args
2022-04-11 14:58:48adminsetgithub: 74910
2020-04-26 05:22:09zach.waresetstatus: open -> closed
resolution: out of date
stage: resolved
2017-06-22 16:24:09KevKeatingsetmessages: + msg296643
2017-06-22 16:12:44eryksunsetmessages: + msg296642
2017-06-22 15:48:39paul.mooresetmessages: + msg296640
2017-06-22 15:40:26eryksunsetnosy: + eryksun
messages: + msg296638
2017-06-22 15:16:03steve.dowersetmessages: + msg296636
2017-06-22 14:52:00KevKeatingsetmessages: + msg296634
2017-06-22 14:39:50paul.mooresetmessages: + msg296632
2017-06-22 14:20:59KevKeatingsetfiles: + log.txt

messages: + msg296631
2017-06-21 19:26:34steve.dowersetmessages: + msg296575
2017-06-21 17:59:07KevKeatingcreate