I think I’m starting to be able to see them as they happen. I run the built-in Windows Package Manager (WinGet, aka Microsoft.AppInstaller) daily, so I get to see it act up pretty often. Yesterday, I found myself updating Python.Launcher repeatedly and endlessly. I had to wonder: could this be another WinGet version mismatch. Sure enough, that’s exactly what it was. Let me explain…
How I Identified Another WinGet Version Mismatch
As I was noodling about with the unending sequence of Python Launder updates, I thought to myself “Why not try the old uninstall/reinstall manuever?” This is actually a valid nostrum for many WinGet gotchas and hiccups, so it wasn’t a bad thought. If you look at the lead-in graphic, you can see what happened when I tried that very thing, which produced a major clue. It reads (in red text):
Multiple versions of this package are installed. Either refine the search, pass the ‘–version’ argument to select one, or pass the ‘–all-versions’ flag to uninstall all of them.
OK, then: there’s proof there is a version mismatch. And indeed the output from WinGet list Python.Launcher reads:
Name Id Version Source ----------------------------------------------- Python Launcher Python.Launcher 3.13.5 winget Python Launcher Python.Launcher < 3.13.5 winget
Notice the mismatch in the two version strings. The lower one has a leading “< ” at the head, which I have to bet is an outright mistake.
Targeted Uninstall Does the Trick!
Looking at the two versions, I have to believe they’re the same, and that one of them has an error in the Version string data. Thus, I targeted that one in a WinGet uninstall directive, to wit:
WinGet uninstall Python.Launcher –version “< 3.13.5”
And, sure enough, that appears to fix the issue. When I run WinGet upgrade … again after that, it comes up with nothing to upgrade, and stays mum on the subject of Python.Launcher. Problem solved. Next!
One More Thing…
Please note that the responsibility for a version mismatch falls on the package developer. They’re the ones who enter the information that goes into the package repository, and define the version strings for what’s known and what’s current. So it’s on them to fix things when this sort of hiccup happens.
That said, I’m going to urge the WinGet developers to write some string checking code for version strings before they’re allowed to be checked into the repository. Two weeks ago a parenthetical phrase in a Visual Studio update also caused the same behaviors. Seems to me that a little “string policing” effort might help head such things off at the pass. Just sayin…
There seems to be a bit of a misunderstanding in this blog post about how WinGet works, and I’d like to clarify.
There are two ways that WinGet performs matching to versions – literal matching and range matching. Which type of matching occurs depends on how the community-submitted manifests for the package were written. In the case of the Python Launcher, range matching is used.
When using range matching, WinGet attempts to take any version that it doesn’t have an exact match for and try to find which version it falls into. When it can’t find which version it belongs to, WinGet will prefix the version with either “” to indicate if it is a lower or higher version than the community submitted manifests specify.
While there is definitely a bug in the implementation (because the infinite upgrade loop shouldn’t have happened), the reason it shows “< 3.13.5" is because the WinGet community has not submitted manifests for all the versions of Python Launcher. This wouldn’t be an issue if literal matching was being used; because the manifest author set it up for range matching, WinGet is saying that it cannot map the version of Python Launcher you have installed to a version that WinGet has data on, but it believes it is older than version 3.13.5.
In summary – there isn’t actually a version mismatch, the community just hasn’t submitted the metadata for the specific version of Python Launcher you had installed.
I say “tomato” and you say “tomatoh.” I think we’re in agreement, but you are distinguishing the “version string that WinGet read” from the “version string that developers provide.” When the developers don’t do what WinGet expects, it has to do something, right? So I’ll stick with my understanding, but thank you for the additional detail and clarification. Alles beste aus Round Rock, TX!
–Ed–