Python will not install on my Windows 7 (64-bit) OS.

I have repeatedly tried the install with variations (specifying an install directly vs. taking the default; running as admininstrator vs. not; with and without logging) and with multiple downloads python-3.4.1.msi, python-3.4.1.amd64.msi, and python-3.4.0.amd64.msi.  No matter what, it always fails with the same symptoms.

msiexec log file is attached.  There are a number of errors indicated on the log, but the one that's fatal seems to be this one:

MSI (s) (24:8C) [14:46:34:848]: Executing op: CustomActionSchedule(Action=UpdatePip,ActionType=3090,Source=F:\Shared.W7\Python34\python.exe,Target=-m ensurepip -U --default-pip,)
CustomAction UpdatePip returned actual error code 3 (note this may not be 100% accurate if translation happened inside sandbox)
MSI (s) (24:8C) [14:46:34:957]: Note: 1: 1722 2: UpdatePip 3: F:\Shared.W7\Python34\python.exe 4: -m ensurepip -U --default-pip 
MSI (s) (24:8C) [14:46:34:957]: Note: 1: 2262 2: Error 3: -2147287038 
Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action UpdatePip, location: F:\Shared.W7\Python34\python.exe, command: -m ensurepip -U --default-pip 
MSI (s) (24:8C) [14:46:41:292]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (s) (24:8C) [14:46:41:292]: Product: Python 3.4.1 -- Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action UpdatePip, location: F:\Shared.W7\Python34\python.exe, command: -m ensurepip -U --default-pip 

Action ended 14:46:41: InstallFinalize. Return value 3.

The same text, "There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor." appears in a message box at the point of failure.

You can always deselect pip from the installation. Running it separately after installation will no doubt show what the actual problem is.

This is the exception that comes out after running the py -m ensurepip manually:


------------------------------------------------------------
C:\Python34\lib\ensurepip\__main__.py run on 08/07/14 15:44:36
Ignoring indexes: https://pypi.python.org/simple/
Downloading/unpacking setuptools
Cleaning up...
  Removing temporary dir C:\Users\venza\AppData\Local\Temp\pip_build_venza...
Exception:
Traceback (most recent call last):
  File "C:\Users\venza\AppData\Local\Temp\tmpz0stj2e6\pip-1.5.6-py2.py3-none-any.whl\pip\basecommand.py", line 122, in main
    status = self.run(options, args)
  File "C:\Users\venza\AppData\Local\Temp\tmpz0stj2e6\pip-1.5.6-py2.py3-none-any.whl\pip\commands\install.py", line 278, in run
    requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)
  File "C:\Users\venza\AppData\Local\Temp\tmpz0stj2e6\pip-1.5.6-py2.py3-none-any.whl\pip\req.py", line 1177, in prepare_files
    url = finder.find_requirement(req_to_install, upgrade=self.upgrade)
  File "C:\Users\venza\AppData\Local\Temp\tmpz0stj2e6\pip-1.5.6-py2.py3-none-any.whl\pip\index.py", line 209, in find_requirement
    file_locations, url_locations = self._sort_locations(locations)
  File "C:\Users\venza\AppData\Local\Temp\tmpz0stj2e6\pip-1.5.6-py2.py3-none-any.whl\pip\index.py", line 128, in _sort_locations
    sort_path(os.path.join(path, item))
  File "C:\Users\venza\AppData\Local\Temp\tmpz0stj2e6\pip-1.5.6-py2.py3-none-any.whl\pip\index.py", line 109, in sort_path
    if mimetypes.guess_type(url, strict=False)[0] == 'text/html':
  File "C:\Python34\lib\mimetypes.py", line 287, in guess_type
    init()
  File "C:\Python34\lib\mimetypes.py", line 348, in init
    db.read_windows_registry()
  File "C:\Python34\lib\mimetypes.py", line 255, in read_windows_registry
    with _winreg.OpenKey(hkcr, subkeyname) as subkey:
TypeError: OpenKey() argument 2 must be str without null characters or None, not str

Presumably the value for subkeyname being passed to OpenKey contains an embedded null, which I believe is legal for the registry in general, but doesn't make much sense in this context and is quite possibly a corruption issue on your machine.

We can certainly strengthen mimetypes against this error (I don't know who's maintaining this module, but handling the TypeError on OpenKey seems safe enough) and you may also want to ensure your virus/malware scanners are up to date - embedded nulls in registry keys are often used to trigger bugs or hide malicious data.

FWIW, on my machine I don't have embedded nulls in any of the values that enum_keys is looking for:

>>> import winreg
>>> hkcr=winreg.OpenKey(winreg.HKEY_CLASSES_ROOT, '')
>>> n = []
>>> i = 0
>>> while True:
...   try:
...     n.append(winreg.EnumKey(hkcr, i))
...   except EnvironmentError:
...     break
...   i += 1
...
>>> [x for x in n if '\0' in x]
[]
>>>

Ok, I had three such keys. I run RegDelNull.exe and managed to remove two of them. The third one is still there.
I'm reasonably sure that this machine is clean, anyway:

1. the Python installer should not fail silently when an exception is thrown during pip installation. There is also a stackoverflow question about "where is pip in python 3.4, I can't find it!" from someone likely having the same problem.

2. ensurepip should not crash on unrelated registry entries it doesn't like, it should just ignore them.

Thanks for the pointer to null keys and the script to find them.

Agreed on both points, but we need to find someone willing to fix the 3.4 installer (I'm completely focused on the 3.5 installer, which won't suffer from the first point).

There's a separate issue tracker for pip which would be the place to get their developers to handle the exception in their code. We should be fixing mimetypes.

I've attached a proposed patch for mimetypes for 3.4 and default. Any concerns/do we know who owns it?

Nobody is listed as a maintainer for mimetypes here https://docs.python.org/devguide/experts.html but I've seen Tim has done some work on it so adding him to nosy list.

This has just come up again over on python-list:

https://mail.python.org/pipermail/python-list/2015-January/696660.html

I'm the nearest thing we have to a mimetypes maintainer at least for Windows so I'll try to pick Steve's patch up.

I don't think the installer needs fixing beyond fixing mimetypes. If ensurepip fails, the whole installation ought to fail (IMO); that's the way MSI is supposed to work. It's the same if some other component could not be installed for some reason (permissions, out of disk space, etc): the entire installation gets rolled back. So I disagree with Steve that it would be desirable to let pip installation fail silently.

This has come up again in issue23604. Steve, please apply your patch. I think it should go against 2.7, 3.4 & 3.5 especially since all those versions now ship with ensurepip.

New changeset 7c4c4e43c452 by Steve Dower in branch '2.7':
Issue #22028: Ensure mimetypes will not open registry keys with embedded nulls
https://hg.python.org/cpython/rev/7c4c4e43c452

New changeset bf2016a1911f by Steve Dower in branch '3.4':
Issue #22028: Ensure mimetypes will not open registry keys with embedded nulls
https://hg.python.org/cpython/rev/bf2016a1911f

New changeset 6ccade563bf7 by Steve Dower in branch 'default':
Issue #22028: Ensure mimetypes will not open registry keys with embedded nulls
https://hg.python.org/cpython/rev/6ccade563bf7

This bug appears (for me) when I use longer install paths, both in the GUI installer and doing a silent install via msiexec. The paths I've used so far are these:

E:\langs\Python\x32\27
E:\langs\Python\x32\34
E:\langs\Python\x64\27
E:\langs\Python\x64\34

E:\Python\x32\27
E:\Python\x32\34
E:\Python\x64\27
E:\Python\x64\34

Both of these paths fail to install when pip is called. If I install to a single-level directory, the install works fine (doesn't matter what drive I use either....)

[Housekeeping] Closing this as fixed. The mimetypes fix is in; the 3.4 installer is well out of support. If any other issues arise on current installers they should be raised as new issues.