Python v3.4.1 x64 on Windows 7 x64.

If the python installation directory is deleted, the installer can not remove, change, or repair the installation.

When I run the python-3.4.1.amd64.msi installer and choose Remove, it gives me a dialog saying a required file is missing about halfway through. It gives me no clue as to what this file is.

If I choose Repair, it gives me a dialog saying "The specified account already exists" about halfway through. Totally cryptic.

If I choose Change and either select that all features or no features will be installed, it gives me a dialog saying "The specified account already exists" about halfway through.

It turns out that the installer is relying on both files in the installation directory and a Windows Intaller key. If the required files are missing, the installer refuses to either remove or repair. If the Windows Installer key still exists, the installer refuses to re-install. When this key is removed, an install can then be done. To be safe, a remove should then be done to clear up any problems and then another clean install.

Both of these requirement violate good MSI practice. You are *NEVER* to use a Windows Installer key as an indication of the installed state because that list can be, and often is, easily corrupted. The installer should always be able to perform a complete repair and especially remove without requiring *ANY* installed files or registry keys.

This installer desperately needs a complete re-write. It should use its own key to indicate whether the application is installed but should not depend on it in case of a partially installed/removed state, should not require any installed file or registry key to fully repair or remove the application, should be able to re-install no matter the state of a previous installation, and should query the user if any information required is missing from the installation or registry. In other words, the normal MSI installer guidelines.

I and at least one other person reporting on python-list have had similar problems trying to update an installation.

I've been working on the rewrite for 3.5 already (progress at http://hg.python.org/sandbox/steve.dower) - redoing the installer completely was one of the conditions for when I signed on to own it.

Martin is still responsible for 3.4, and I'm building 2.7 as required but not working on the installer at all.

If this bug needs to be fixed in 3.4, it should be assigned to Martin. Otherwise, if it only needs to be fixed in 3.5, it can be assigned to me and I'll (try and) remember to make this scenario work. (Basically, uninstall may need to reinstall some files - this is probably the uninstall step for pip, but I'm not 100% sure.)

To find out exactly what isn't working, you should be able to run the following command:

msiexec /l*vx log.txt /x {D54842CB-F761-30BA-881F-1FF821DC44DF}

log.txt can be a full path to any location - the UUID is the product code for 3.4.1 x64. You can attach it here and I'll take a look, or you can check it yourself for the error. Either way, I don't intend to fix it for 3.4.

I had the same issue using Python 3.4.2 x64 on Windows 7 x64 and resolved it by setting PYTHONHOME and PYTHONPATH environmental variables.

I have the same issue on 3.4.3 x64 on Windows 10 x64.

I set PYTHONHOME and PYTHONPATH (Just to C:/Python34), but that didn't fix the problem.

+Martin, who apparently never made it onto nosy.

You should clear those variables, run a Repair, and then uninstall. This error typically is because pip has become corrupted and cannot be removed.

This does not affect Python 3.5 or later.

I deleted those variables and tried running a repair but still got the "specified account already exists" schpeel.
I then tried running an uninstall and got the same error as last time there too.

There's presently no pip at all; there is no python folder on C:/.

I need to see the detailed log to be any more helpful. Can you try running this command and post the log here:

msiexec /l*vx log.txt /x {9529565F-E693-3F11-B3BF-8CD545F5F9A0}

(Note that the UUID is different from earlier because it matches 3.4.3.amd64 and the previous was for another version)

Running that in my command prompt outputs "Access is denied," even after disabling UAC.
Running that in bash just gives me a popup for Windows Installer.

Is the UUID going to be different for 3.4.3 intel x64 (I have intel, not amd)?

Start from an elevated command prompt. There's only one 64-bit build, so that'll be it. Our name for it is amd64, even though it applies to both Intel and AMD.

My log.txt: http://puu.sh/jqLWR.txt

Turns out that my antivirus was blocking that command from running before.

Thanks. Unfortunately I can't get anything helpful from that log because it's failing too early. It seems like you have some corruption in your Windows installer database, since it isn't even getting far enough into the Python installer. I'd track down a troubleshooter or reputable system cleaner and see if you can clean up your system.

I managed to resolve the issue following these steps:
1. Installing Python 3.4.3 on another computer (not even the same architecture)
2. Copying the Python34 folder from that other computer to the computer I broke
3. Running the uninstaller for Python 3.4.3
4. Reinstalling Python 3.4.3 normally as it is now removed correctly

I also replicated this error in 2.7.10 and fixed it with only slightly different steps:
1. Installing Python 2.7.10 on another computer (again, not even the same architecture as the broken computer)
2. Copying the Python27 folder from that other computer to the computer I broke
3. Running the repair tool for Python 2.7.10
4. Running the uninstaller for Python 2.7.10
5. Reinstalling Python 2.7.10 normally as it is now removed correctly

I replicated the issue in 2.7.10 again afterwards, and it does appear that step 3 is required.

> This does not affect Python 3.5 or later.

Closing as out of date as 3.4 is no longer maintained.