Hello, I am working in an IT group, attempting to automate our management of python. This issue applies to both Python 3.4 and Python 2.7.5 and Python 2.7.4

On a Windows machine (both 7 and 8.1 have been tested) when python msi's are installed from the command line using a quiet or passive mode, they do not appear in the "Programs and Features" panel. This leads me to believe that there are missing registry entries when installed in this mode.

When the same msi is used, but in interactive mode, everything appears to install correctly. While I am able to install and uninstall normally using the command line, this creates issues for manual uninstallation of python, as well as for managing it with automation tools like puppet.

I've noticed this as well. I'm hoping to do a significant rework of the installer for 3.5 and will keep this in mind, but I honestly have no idea how to diagnose this in the current setup.

Windows Installer is responsible for the missing entries, and AFAIK the only way it will fail to create them is if our MSI includes invalid data (I'd expect this to show up in the verbose logs). Alternatively, there may be some obscure component flags that 'work' but sometimes don't work, I really don't know.

This may actually be a Windows issue... the keys for uninstall are being written to the Wow6432Node of the registry (on a 64-bit machine), and apparently the Programs and Features panel does not read them from there.

The 64-bit installers should be fine (testing one now) since they probably don't redirect the registry writes.

I actually have more than twice as many entries under here than in the main view - mostly Visual Studio components - and none of them appear in the panel. I'll try and ping some people here and find out how to fix it.

Apparently keys in Wow6432Node are actually okay, so I'm not much closer to figuring this out. As far as I can tell, the entry I have for Python 2.6.6 (which doesn't appear) has identical information to IronPython 2.7.4 (which does appear).

Okay, now it looks to me like the install that 'works' ran under the SYSTEM account while the one that didn't work ran under my (admin) user account.

This may be caused by running the installer from an elevated command prompt. If it detects that it needs to elevate, then it changes to SYSTEM, but if it detects that it doesn't, it will use the current account.

If you can run your install scripts as SYSTEM then I suspect it will work. I'm not yet clear on why it sometimes installs through the one account instead of the other.

Jason: can you please report how exactly you attempted to perform the installation?

I cannot reproduce the issue. In an elevated terminal, I run

msiexec /i python-3.4.1.amd64.msi /qn /l*v python.log ALLUSERS=1

Python installs fine, and does appear in the "Remove programs" panel.

The difference may be the "ALLUSERS=1" option. Windows Installer is supposed to auto-detect this when an installer is run as an admin, but maybe something in our authoring is preventing this detection?

When I get a chance I'll try both and see if the logs show whether this is the case.

Steve: how is the auto-detection supposed to work, and what is the rationale? Shouldn't it be possible that even someone with administrator privileges still might want to install "just for me"? And how would they then specify that on the command line, given that ALLUSERS can only be set, not reset?

It's described at http://msdn.microsoft.com/en-us/library/aa367559(v=vs.85).aspx, and frankly it is incredibly confusing.

It is possible to reset ALLUSERS on the command line by specifying ALLUSERS=""

Much of the text refers to Installer 5.0. msi.py currently targets installer 2.0. Does the auto-detection also work on such installers?

No idea, TBH, though I'd guess that the behaviour comes from the installed version of Windows Installer and the database schema comes from the authored version.

Nonetheless, if the solution is to add "ALLUSERS=1" to the command line when doing silent all-user installs, I'm okay with documenting that as being the fix for 2.7 and 3.4.

For Python 3.5, Windows Vista is the earliest supported platform, and so we can assume Windows Installer 4.0 or later (not that there's any need to take advantage of it) ref: http://msdn.microsoft.com/en-us/library/cc185688(v=vs.85).aspx

I realize this hasn't been commented on for a long time, but I'm noticing the same issue trying to do a silent install with the 3.4.3 x64 windows installer.  The 3.4.2 x64 windows installer worked perfectly fine, but I can't seem to get the registry and add/remove entries to work with 3.4.3.  I tried fiddling with ALLUSERS="1" and ALLUSERS="" and the results were the same.

Were there any changes to the windows x64 installer from 3.4.2 to 3.4.3 in regards to this issue?

I'm not exactly sure how msiexec does its parsing, but it's possible that ALLUSERS="1" may not actually be the same as ALLUSERS=1. I use the latter regularly with most versions of Python in existence and it works fine.

There may also be problems upgrading from the previous installation. If you run the old installers then they may offer to remove Python, even if it doesn't show up in Programs and Features.

As all versions using the MSI installer are now out of support, I'm closing the issue.