[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

[denelon]

I'm looking into it.

[mdanish-kh]

Now that #122472 is merged, @tsunamistate Can you check if you're still facing this issue?

[tsunamistate]

The error when attempting to upgrade is fixed, but upgrading doesn't make the prompt to go away
It shouldn't prompt to upgrade anyway, that's what the issue is about

[mdanish-kh]

upgrading doesn't make the prompt to go away It shouldn't prompt to upgrade anyway, that's what the issue is about

@tsunamistate That was explained in #122168 (comment). As far as I understand, Python Launcher is a standalone package different from regular installation of Python. The launcher can be upgraded irrespective of what the current installation of Python is. winget will offer that upgrade to you, but if you decide that you want to stick to 3.11 version you can set a gating pin and lock Python.Launcher to 3.11.x versions. You can do this with this command

winget pin add Python.Launcher --version 3.11.*

If there's a way to mark its manifest as "do not auto-upgrade", that will cut down on complaints.

There is a way to exclude the package from winget upgrade --all flow by adding RequireExplicitUpgrade: true in the manifest but I don't think we really need to be doing that for this package.

[tsunamistate]

I know about the pinning, but this is a workaround, and not a fix

[zooba]

Maybe the better state would be "only upgrade if it was installed by winget", which would actually have solved a number of other issues I've faced due to winget on my own machine (I don't use it, but some automated tools do, and they've broken things I installed manually).

However, if the upgrade had silently worked, this issue wouldn't exist. Making sure that upgrade detection gets the scope right would be best.

[tigerinus]

same issue also happens to Go installer.

Latest is 1.21.x but team requirement is 1.20.x. However winget keeps upgrading it to latest.

[lackovic]

The installation succeeds running upgrade from an elevated shell but the same version is proposed again regardless on the next upgrades:

> winget upgrade -h --all
Name            Id              Version  Available Source
---------------------------------------------------------
Python Launcher Python.Launcher < 3.12.0 3.12.0    winget
2 upgrades available.

The following packages have an upgrade available, but require explicit targeting for upgrade:
Name    Id              Version  Available Source
-------------------------------------------------
Discord Discord.Discord 1.0.9012 1.0.9018  winget
2 package(s) have version numbers that cannot be determined. Use --include-unknown to see all results.

Installing dependencies:
(1/1) Found Python Launcher [Python.Launcher] Version 3.12.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://www.python.org/ftp/python/3.12.0/win32/launcher.msi
  ██████████████████████████████   540 KB /  540 KB
Successfully verified installer hash
Starting package install...
Successfully installed

> winget --info
Windows Package Manager v1.6.2771
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22621.2506
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.21.2771.0

The logs:
WinGet-2023-11-08-09-45-56.320.log

[beingmerry]

The only fix that worked for me was going to Add or remove programs and uninstalling every instance of Python Launcher that was not 3.12.

Not a fix if you need those older launcher versions, but it does remove the Python.Launcher from the winget upgrade list of packages.

❯❯ ~  09:10 winget upgrade
Name            Id              Version  Available Source
---------------------------------------------------------
Python Launcher Python.Launcher < 3.12.0 3.12.0    winget
1 upgrades available.
❯❯ ~  09:11 winget upgrade
No installed package found matching input criteria.

[zooba]

@beingmerry How many instances did you have? There's only ever been a single installer for the Python Launcher (with the exception of 1-2 broken releases that should have been removed by later versions of the installer).

If you had more than one launcher installed, something else is going wrong for you.

[beingmerry]

@zooba I had installed Python from 3.9, then 3.11, then 3.12. I uninstalled the Python launcher from 3.9. not sure why I had multiple versions when you are saying there was ever only one version...

[zooba]

Note that the Python install is separate from the Python Launcher install. Each Python install also bundles the launcher, and will upgrade it from previous versions to the one that it bundles. Removing the Python install won't affect the launcher it installed.

But I guess they're all gone now, so we can't figure out how you ended up with multiple.

[lackovic]

we can't figure out how you ended up with multiple.

I also had multiple installations (two 3.11 besides the 3.12) I wasn't aware of, I only ever needed one and always used only winget to install and upgrade it. I have no idea how multiple versions ended up being installed. After I removed the older redundant versions the problem was solved for me.

[zooba]

Given you've both commented here, I assume you're winget users. So presumably there's something about how winget installs Python that messed up the registration of the launcher.

I looked in a few manifests but nothing jumps out as an obvious issue. But I'm assuming that the installer just gets run directly with the command line options and relies on our Burn bundle to do the registration - if anything more complex is going on, then it's beyond me.

[ascendedguard]

I had the same issue today where Python Launcher showed Version < 3.12.0, Available 3.12.0 and an upgrade had the line remain. I had run the command: winget upgrade Python.Python.3.11 Python.Launcher

Checking Add / Remove Programs after upgrading everything through winget, I had Python 3.11.6 installed (also confirmed via py --version, and both Python Launcher 3.11 and Python Launcher 3.12, presumably 3.12 launcher was installed via winget upgrade while leaving 3.11. Manually uninstalling Python Launcher 3.11 does remove the suggestion from winget upgrade.

I'm fine running the latest, so I uninstalled Python 3.11 too and manually installed 3.12, although now it confusingly wants to upgrade to 3.12 as part of Python.Python.3.11:

[JLOrdaz]

I have the same issue @ascendedguard . Unistall 11 and install 12, and run winget upgrade and I have the same > 3.11 3.12

[BDisp]

I had version 3.9.0 and 3.12.0 installed and after removing version 3.9.0 through the installed applications, > 3.12.0 3.12.0 no longer appears in winget.