classification
Title: Windows AllUsers installation places uninstaller in user profile
Type: behavior Stage: needs patch
Components: Installation, Windows Versions: Python 3.7, Python 3.6
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: steve.dower Nosy List: chrullrich, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2015-09-18 11:18 by chrullrich, last changed 2017-08-16 15:54 by steve.dower.

Messages (10)
msg250962 - (view) Author: Christian Ullrich (chrullrich) * Date: 2015-09-18 11:18
A system-wide installation on Windows (using InstallAllUsers=1) still places the uninstall executable into the profile (%LOCALAPPDATA%) of the installing user. If that user profile is deleted, the (system-wide) installation cannot be removed anymore.

Ceterum censeo: This bug would have been avoided by using MSI as the distribution package format.
msg251384 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-09-23 01:16
Burn is always started in the per-user scope so that we can do per-user installs without elevating, but it looks like we need to manually change this once we know it's an all-users install.
msg251395 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2015-09-23 02:17
Where is the API documented to change the install scope dynamically? I see where it's apparently defined in the burn manifest (extracted from the executable) as PerMachine="no":

    <BurnManifest xmlns="http://schemas.microsoft.com/wix/2008/Burn">
      <....>
      <Registration Id="{e599f76f-2b95-44da-a280-77548b1b2a21}" 
                    ExecutableName="python-3.5.0-amd64.exe" 
                    PerMachine="no" 
                    Tag="" 
                    Version="3.5.150.0" 
                    ProviderKey="{e599f76f-2b95-44da-a280-77548b1b2a21}">
        <Arp Register="yes" 
             DisplayName="Python 3.5.0 (64-bit)" 
             DisplayVersion="3.5.150.0" 
             Publisher="Python Software Foundation" 
             AboutUrl="http://www.python.org/" 
             DisableModify="button"/>
      </Registration>
msg251396 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-09-23 02:23
Not sure yet :)

There are a lot of undocumented (or not-yet-documented) APIs accessible from the bootstrap app and I haven't gone through them yet - see https://github.com/wixtoolset/wix3/tree/develop/src/libs, probably dutil.

It may also be something that we have to request or contribute to WiX.
msg251878 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-09-29 19:26
After discussing it on the WiX mailing list, this definitely requires a change to WiX.

Currently, as soon as you include any per-user packages in your bundle the entire registration is forced to per-user regardless of whether or not they are ever installed.

I'm going to propose a change where the bootstrap application can assert that the bundle should be registered for the whole machine, so that when we start installing we can correct it. Can't be sure it'll be available for 3.5.1, but some time in 3.5's lifetime we should get this fixed.
msg251882 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-09-29 19:58
WiX issue is http://wixtoolset.org/issues/4914/
msg279451 - (view) Author: Christian Ullrich (chrullrich) * Date: 2016-10-25 19:49
This bug has been open for over a year and two subsequent releases, and its planned resolution depends on a change to WiX. The related WiX bug (see comment above) is scheduled to be implemented in WiX 4.0, which has no prospective release date. According to <https://github.com/wixtoolset/issues/milestone/4>, only 27 percent of the issues currently planned for this release are resolved.

In my opinion, this is an important bug that cannot wait indefinitely.

Ceterum censeo (yes, there had to be one): This is particularly true when considering that a (relatively) simple fix exists that can be done by the Python project alone, with no external dependencies. I am referring, of course, to dropping the burn bundle entirely and shipping a single MSI package again, rather than 43 (!) of them (across x86 and amd64) with an average of ~190 and a median of 8 (eight) installed files per package in 3.5.2, counting pip.
msg279453 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2016-10-25 20:05
Christian, your desire for a single MSI is well known, and repeatedly stating that desire is far more likely to raise ire rather than spur change.  No, you did not need to include "ceterum censeo".

The installer system that Steve created for us has many features that I and many others would be very sad to see disappear again, and which cannot be supported by a single MSI distribution.  In particular, selecting which components to install and only downloading those components is a wonderful feature for anyone with a low-bandwidth or metered internet connection.

If the current installer is unusable to you, feel free to forward-port the old 3.4 installer system and create your own installers.  Alternately, feel free to provide patches to resolve this or any other issues you have with the current installer.
msg279454 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-10-25 20:10
I won't be changing the official releases to be a single MSI again - the experience is too hostile towards regular users.

As my (volunteer) time allows, I've been working on resolving the issue in WiX and we are totally capable of moving to a private build of WiX that includes a fix. There is no need to wait for 4.0.

If you would like a single MSI installer, I'd suggest offering some time (or paying someone to spend their time) to develop one and distribute it independently. The old installer might be a good starting point, but it had a range of issues that have been resolved by the new installer. There are also a number of features available in the new installer that are not available under a single MSI (such as per-user installs, installing/skipping the CRT, and disabling MAX_PATH limitations). However, if your installer becomes more popular than the official one, it will be strong evidence that people would rather have one monolithic installer with less reliable options, and we can consider switching back to that format.
msg300371 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-08-16 15:54
There are no more binary installers for 3.5, so updating the target versions.

I have some ideas about how to do this and will hopefully get time at the dev sprints to try them out.
History
Date User Action Args
2018-02-08 19:34:02steve.dowerlinkissue32791 superseder
2017-08-16 15:54:23steve.dowersettype: behavior
stage: needs patch
messages: + msg300371
versions: + Python 3.6, Python 3.7, - Python 3.5
2017-02-03 18:25:44steve.dowerlinkissue29437 superseder
2016-10-25 20:10:25steve.dowersetmessages: + msg279454
2016-10-25 20:05:07zach.waresetmessages: + msg279453
2016-10-25 19:49:07chrullrichsetmessages: + msg279451
2016-02-22 22:08:10eryksunlinkissue26413 superseder
2015-09-29 19:58:09steve.dowersetmessages: + msg251882
2015-09-29 19:26:32steve.dowersetmessages: + msg251878
2015-09-23 02:23:20steve.dowersetmessages: + msg251396
2015-09-23 02:17:13eryksunsetnosy: + eryksun
messages: + msg251395
2015-09-23 01:16:32steve.dowersetassignee: steve.dower
messages: + msg251384
2015-09-23 01:08:14steve.dowerlinkissue25162 superseder
2015-09-18 11:18:10chrullrichcreate