Winget confuses vim.vim and vim.vim.nightly

[Atario]

Brief description of your issue

I installed vim.vim (currently at v. 9.1.1039), but afterward, winget thinks I have vim.vim.nightly installed and therefore offers to "upgrade" it (to v. 9.1.1071).

Steps to reproduce

1. Install vim.vim (only when the vim.vim.nightly version doesn't match, I presume).
2. Do winget list vim and/or winget upgrade

Expected behavior

Package is shown as vim.vim and no upgrade is offered.

Actual behavior

Package is listed as vim.vim.nightly and an available upgrade is shown.

Environment

Windows Package Manager v1.9.25200
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22631.4751
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.24.25200.0

[stephengillie]

This should probably be moved to the winget-pkgs repo, as it only affects a couple of packages. I'm guessing they share some common metadata, and might need more details described in the manifest to differentiate them better.

(edit: certainty)

[Atario]

They seem to think it's a problem for here:

microsoft/winget-pkgs#222278

[stephengillie]

Apologies for the circular routing.

[Trenly]

[Policy] Area-Matching
[Policy] Issue Bug

[jacktose]

I can replicate this:

$ winget --version
v1.9.25200

$ winget search vim.vim
Name Id              Version  Source
-------------------------------------
Vim  vim.vim         9.1.1039 winget
Vim  vim.vim.nightly 9.1.1101 winget

$ winget list vim
Name          Id              Version  Available Source
-------------------------------------------------------
Vim 9.1 (x64) vim.vim.nightly 9.1.1039 9.1.1101  winget

$ winget uninstall vim.vim.nightly
Found Vim 9.1 (x64) [vim.vim.nightly]
Starting package uninstall...
Successfully uninstalled

$ winget install --exact --id vim.vim --verbose
Found Vim [vim.vim] Version 9.1.1039
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://github.com/vim/vim-win32-installer/releases/download/v9.1.1039/gvim_9.1.1039_x64.exe
  ██████████████████████████████  10.6 MB / 10.6 MB
Successfully verified installer hash
Starting package install...
The installer will request to run as administrator, expect a prompt.
Successfully installed

$ winget list vim
Name          Id              Version  Available Source
-------------------------------------------------------
Vim 9.1 (x64) vim.vim.nightly 9.1.1039 9.1.1101  winget

I don't know the internal logic of the upgrade commands, but looking at the end of the list of manifests for package versions:

• vim
  • ...
  • 9.1.0927
  • 9.1.1039
  • nightly

I wonder if it's as simple as nightly sorting to the end of the (otherwise numeric) list?

[denelon]

Do the nightly builds generate any unique entries to distinguish between "stable" and "nightly" builds for the Apps&Features entries? If they don't then WinGet has no way to disambiguate between them.

[jacktose]

I'm not sure what that means. I'll check if you can explain where to look.

They have different PackageIdentifiers: vim.vim, vim.vim.nightly. Shouldn't that be enough that winget doesn't upgrade one to the other?

[Trenly]

I'm not sure what that means. I'll check if you can explain where to look.

They have different PackageIdentifiers: vim.vim, vim.vim.nightly. Shouldn't that be enough that winget doesn't upgrade one to the other?

Apps&FeaturesEntries refers to the data that the application writes into the registry to tell Windows exactly what application is installed. You can get most of the information using appwiz.cpl in the run dialogue and finding the installed information for vim.

Alternatively, you can use this PowerShell function to return your entire Apps&FeaturesEntries table.

function Get-ARPTable {
    $registry_paths = @('HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*', 'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*', 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*', 'HKCU:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*')
    return Get-ItemProperty $registry_paths -ErrorAction SilentlyContinue | 
    Select-Object DisplayName, DisplayVersion, Publisher, @{N = 'ProductCode'; E = { $_.PSChildName } } |
    Where-Object { $null -ne $_.DisplayName }
}

---

WinGet, like most other Windows Components, uses the information in the Apps&FeaturesEntries to determine exactly what is installed. The best practice is for each application to have its own ProductCode that gets written so that each package can be identified separately; however, not all publishers do this.

If both the nightly and the stable version write the exact same data to the registry, then to any Windows Component looking in, then there is no way to identify the channel that was installed.

[Trenly]

@denelon - After more investigation, it looks like these packages *do* in fact write the same data to AppsAndFeaturesEntries.

--> Installing WinGet
--> Disabling safety warning when running installers
Tip: you can type 'Update-EnvironmentVariables' to update your environment variables, such as after installing a new software.

--> Configuring Winget
Enabled admin setting 'LocalManifestFiles'.
Enabled admin setting 'LocalArchiveMalwareScanOverride'.

--> Installing the Manifest 9.1.1094

Found Vim [vim.vim.nightly] Version 9.1.1094
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://github.com/vim/vim-win32-installer/releases/download/v9.1.1094/gvim_9.1.1094_x64.exe
  ██████████████████████████████  10.6 MB / 10.6 MB
Successfully verified installer hash
Starting package install...
Successfully installed

--> Refreshing environment variables

--> Comparing ARP Entries

DisplayName   DisplayVersion Publisher       ProductCode Scope
-----------   -------------- ---------       ----------- -----
Vim 9.1 (x64) 9.1.1094       The Vim Project Vim 9.1     Machine

PS C:\Users\WDAGUtilityAccount\Desktop\winget-pkgs> winget install vim.vim --force; Get-ARPTable | Format-Table

Found Vim [vim.vim] Version 9.1.1039
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://github.com/vim/vim-win32-installer/releases/download/v9.1.1039/gvim_9.1.1039_x64.exe
  ██████████████████████████████  10.6 MB / 10.6 MB
Successfully verified installer hash
Starting package install...
Successfully installed

DisplayName           DisplayVersion Publisher             ProductCode           Scope
-----------           -------------- ---------             -----------           -----
Vim 9.1 (x64)         9.1.1039       The Vim Project       Vim 9.1               Machine

[Trenly]

@chrisbra - Tagging you as I see your username associated with the latest submissions of Vim over at winget-pkgs.

1. Would it be possible to get a different product code for the nightly builds?
2. If not, can the nightly builds be deprecated / removed from WinGet leaving only the stable package?

• Blocked by Support different release channels [released, beta, alpha] #147

[chrisbra]

Would it be possible to get a different product code for the nightly builds?

I don't get that. What does that mean? We are using nightly.yml and stable.yml to release under different projects. What exactly should be changed here?

[Trenly]

@chrisbra - The issue is that the installer for both stable amd nightly write the same uninstall entries to the Registry (I belive this happens in dosinst.c?).

This means that Windows Components perceive the nightly and the stable as the same package.

The only real way for them to be separate applications is to have them under different Product Codes (hRootKey using the syntax from dosinst.c). WinGet may be able to differentiate them without different root keys, if the stable package and nightly have a different value for DisplayName. For example, if stable were Vim 9.1 (x64) and nightly were Vim Nightly 9.1 (x64)

[chrisbra]

But that would require a source change to differentiate the two channels . That is not how it works. Each change to the source is a stable version. Since we release a few patches every day, that would mean we have a new stable release every day (which annoys some users). Therefore, we split this up, use the nightly for the daily patches and roughly every hundred patches one release is promoted to the stable "channel".

[Trenly]

But that would require a source change to differentiate the two channels . That is not how it works. Each change to the source is a stable version. Since we release a few patches every day, that would mean we have a new stable release every day (which annoys some users). Therefore, we split this up, use the nightly for the daily patches and roughly every hundred patches one release is promoted to the stable "channel".

Understandable. In that case, I think a decision needs to be made as to whether -

1. This will be left as-is, with WinGet being unable to differentiate between the stable and nightly channels until Support different release channels [released, beta, alpha] #147 is implemented

- or -

2. vim.vim.nightly should be removed from WinGet until Support different release channels [released, beta, alpha] #147 is inplemented. This means that only stable releases would be offered through WinGet, anyone on an older nightly would be offered updates to the latest stable through WinGet, but anyone on a nightly that is newer than stable would not see an update available in WinGet