[Package Issue]: winget suggests upgrading Python.Launcher to 3.12 when Python 3.11 is installed

[tsunamistate]

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

Other

Brief description of your issue

I currently have Python 3.11.6 installed, and don't want to upgrade yet

However, winget suggests upgrading Python.Launcher package to 3.12

Attempting to upgrade gets the following error:

Question: why does Python.Launcher have a separate manifest? AFAIK, Python launcher is an optional feature invoked from Python installer, its version matches the version of Python installed, and it doesn't have a separate update mechanism

Steps to reproduce

1. Have Python 3.11 with "py launcher" feature installed
2. Execute winget upgrade from CMD or PowerShell prompt

Actual behavior

winget suggests upgrading Python.Launcher to 3.12

Expected behavior

winget doesn't suggest upgrading Python.Launcher to 3.12 since Python 3.11 is installed

Environment

Windows Package Manager v1.6.2771
Windows: Windows.Desktop v10.0.22621.2361
Package: Microsoft.DesktopAppInstaller v1.21.2771.0

Screenshots and Logs

No response

[mdanish-kh]

Looking at the discussion in #121195 and this issue, I'm still unsure if this package is to be treated as its own separate package or something that should be installed only when its matching standalone Python version is present? Does the version of Python launcher has to match the version of standalone python? If that's the case then we should break the PackageId into Python.Launcher.3.12 as was originally done by @Dragon1573 and add Python Launcher package for previous versions too.

I suggested that this package should have its own PackageId that isn't divided into its minor version since I assumed it to be a standalone package (and also one that does not install side-by-side). But looking at the error message it seems one cannot upgrade to Python Launcher 3.12 if corresponding 3.12 installation of Python isn't present correct?

cc @zooba from the original package request

[Dragon1573]

@tsunamistate For Winget version v1.6, you can just "pin" that package as a walkaround. Winget will ignore that package when you invoke winget update.

If it really needs exactly version matching, I can create pull requests for fixing this.

[Trenly]

If it really needs exactly version matching, I can create pull requests for fixing this.

This won’t work, because of some issues with how winget performs correlation. This is being tracked at winget-cli with the Area-Matching label

[zooba]

The launcher does not need exact version matching with anything, it stands alone.

It's not an optional feature of the CPython installer, it's more of an optional bundled product. You can see this by uninstalling Python 3.11 - the launcher remains behind and has to be uninstalled separately (or alternatively, you can install multiple different versions of CPython and notice that there's only one launcher installed).

I don't understand why that dialog pops up. It looks like a broken MSI file association and using the shell to launch the MSI, but I'd have expected WinGet to use at least msiexec to launch an MSI, if not even lower-level APIs. Those should not produce that kind of error message.

In any case, this is likely to be a source of complaints, and I'm sure we'll all get sick of explaining that the launcher is actually separate from Python. If there's a way to mark its manifest as "do not auto-upgrade", that will cut down on complaints.

[mdanish-kh]

So finally got to test the installer and here's what I could find:

The issue is actually related to microsoft/winget-cli#3011. The problem is that although this (and almost every other) WiX installer installs to %LOCALAPPDATA% for user scope but it writes the registry uninstall entries to HKEY_LOCAL_MACHINE instead of HKEY_CURRENT_USER. Since WinGet gets its package metadata from the Registry, this makes WinGet incorrectly think that the current installation is in machine scope. Because of this correlation, WinGet will actually try to update to the machine scope installer node defined in -

winget-pkgs/manifests/p/Python/Launcher/3.12.0/Python.Launcher.installer.yaml

Lines 32 to 38 in f6b03e9

	- Architecture: x86
	Scope: machine
	ElevationRequirement: elevationRequired
	InstallerUrl: https://www.python.org/ftp/python/3.12.0/win32/launcher.msi
	InstallerSha256: 3A0DAA56286B02546438D24F158A334F4936B5EB027BECCDA60EAA0B39C075BA
	InstallerSwitches:
	Custom: ALLUSERS=1

which would try to pass ALLUSERS=1 to the installer and if user is not in an elevated shell, it will cause the installation to fail with the error dialog seen in this issue.

---

The temporary workaround here is to not support explicit scopes in the manifest and let the installer execute with default args. This should work fine for majority of the users. For anyone that would want a true machine-based installation would have to use the --override flags and provide it manually to the installer. Something like winget install Python.Launcher --override "/quiet /norestart ALLUSERS=1"

[zooba]

The problem is that although this (and almost every other) WiX installer installs to %LOCALAPPDATA% for user scope but it writes the registry uninstall entries to HKEY_LOCAL_MACHINE instead of HKEY_CURRENT_USER.

This makes no sense, but it does seem to be what's happening. Windows Installer must be doing it though, because the installer itself doesn't have permission to modify HKLM (e.g. passing ALLUSERS=1 without elevation fails because it tries to install somewhere it can't).

Has anyone checked with the Windows Installer team whether this is intentional? It seems like it would mess up if multiple users installed the same per-user product, which is supposed to be supported with user scoped installers.

[mdanish-kh]

Has anyone checked with the Windows Installer team whether this is intentional?

There is some discussion around the topic in microsoft/winget-cli#3011 and a response from the WiX installer team in the issue.

[zooba]

WiX is not Windows Installer. The MSI file itself doesn't specify where uninstall/registration information should be stored, and generating that file is all WiX is concerned with. Windows Installer is the team at Microsoft who actually install the files based on the MSI.

[mdanish-kh]

Has anyone checked with the Windows Installer team whether this is intentional?

cc @denelon