[Package Issue]: Python.Python SYSTEM account context issues

[luke-patchblox]

Please confirm these before moving forward

• I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
• I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue

Installation issue.

Brief description of your issue

The python installer package has multiple issues when being silently installed/uninstalled under the system account.

ISSUE 1: After installing Python thru winget, a winget list does NOT show Python as installed.
The installer logic being used when installing system wide (iow, not per user) adds registry entries into the HKEY_USERS.DEFAULT\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall registry hive.
The installer should be adding these registry entries to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall when installing system wide.

ISSUE 2: Attempting to uninstall Python thru winget (after successfully install thru winget under the SYSTEM account context) will fail with application not found.
This can cause major issues that require manual intervention and running the cached python msi. This issue is related to ISSUE 1.

Ultimately, this is a BUG in the Python installer and NOT the package info. This needs to be resolved by the vendor.

Steps to reproduce

Install any Python package within a SYSTEM account context.

Actual behavior

Machine-wide installation is installing to the HKEY_USERS.DEFAULT\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall registry hive.

Expected behavior

Machine-wide installation should be installing to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

Environment

Windows Package Manager v1.8.1911

Copyright (c) Microsoft Corporation. All rights reserved.
 
Windows: Windows.Server v10.0.20348.2655

System Architecture: X64
 
Winget Directories                 

------------------------------------------------------------------------------------------------------

Logs                               %TEMP%\WinGet\defaultState

User Settings                      %LOCALAPPDATA%\Microsoft\WinGet\Settings\defaultState\settings.json

Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links

Portable Links Directory (Machine) C:\Program Files\WinGet\Links

Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages

Portable Package Root              C:\Program Files\WinGet\Packages

Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages

Installer Downloads                %USERPROFILE%\Downloads
 
Links               

---------------------------------------------------------------------------

Privacy Statement   https://aka.ms/winget-privacy

License Agreement   https://aka.ms/winget-license

Third Party Notices https://aka.ms/winget-3rdPartyNotice

Homepage            https://aka.ms/winget

Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale
 
Admin Setting                             State

--------------------------------------------------

LocalManifestFiles                        Disabled

BypassCertificatePinningForMicrosoftStore Disabled

InstallerHashOverride                     Disabled

LocalArchiveMalwareScanOverride           Disabled

ProxyCommandLineOptions                   Disabled

DefaultProxy                              Disabled

Screenshots and Logs

No response

[denelon]

@luke-patchblox there are plenty of challenges with system context installs. Generally, it boils down to how the "installer" behaves. I've been thinking about how we could add some additional decoration in manifests to indicate what needs to be done differently for system context, or optionally something that means "this isn't going to work" (installing in system context for a single user is a great example).

[dave-patchblox]

I agree that providing specific decorations around this would be very useful. In my opinion, installers should HAVE to indicate whether they support system wide installs and per user installs. If they support system wide installs, then when in installing system wide, REGARDLESS of the user context (which needs to be someone in the administrators group including the built-in SYSTEM account), they must properly install so that they are visible to winget as an installed application. If the application is NOT visible to winget as installed, then the package is not valid and should not be approved and allowed in the repository. This test could be added as a part of the automated validation process. This is a best practices/guidelines issue that ISVs should be following when building installers. If the ISVs are unable to build to those guidelines, then they will not be able to participate in the winget repo.