Allow updating a manifest with a different number of installer URLs

[RuiNtD]

Description of the new feature / enhancement

Hello. I'm trying to update a package (PolyMC.PolyMC) that has stopped distributing 64-bit exes and I can't update the manifest because of this error:

Updating a manifest is only supported with the same number of installer URLs.

This error should be a warning instead, prompting the user if they want to continue anyways.

Proposed technical implementation details

No response

[Trenly]

@FayneAldan - Just an FYI; PolyMC actually has a bot that submits their releases automatically https://github.com/microsoft/winget-pkgs/pull/67332

[RuiNtD]

Yes, I am aware. I tried to update the package manually after Winget Releaser picked the wrong installers, but Winget Create wouldn't let me do it.

[ryfu-msft]

Hey @FayneAldan,

We actually do support your scenario. The reason why it didn't work is because the manifest of the latest version of PolyMC (v1.4) only has one installer URL which has already been checked in. We always use the latest version for the update. If that manifest wasn't checked in, you could have done something like this:

wingetcreate update PolyMC.PolyMC --urls "https://github.com/PolyMC/PolyMC/releases/download/1.3.0/PolyMC-Windows-x86_64-Setup-1.3.0.exe" "https://github.com/PolyMC/PolyMC/releases/download/1.3.0/PolyMC-Windows-i686-Setup-1.3.0.exe"

Winget-Create already has logic to help match the installers with the correct architecture but if you find that it didn't match it correctly, you can also override the detected architecture:

wingetcreate update PolyMC.PolyMC --urls "https://github.com/PolyMC/PolyMC/releases/download/1.3.0/PolyMC-Windows-x86_64-Setup-1.3.0.exe|x64" "https://github.com/PolyMC/PolyMC/releases/download/1.3.0/PolyMC-Windows-i686-Setup-1.3.0.exe|x86"

Just fyi, in case you ever try this again in the future :)

[Jaifroid]

Well, I'm also getting this error but with manifests that have two entries for the SAME installer/architecture, due to scope user and scope machine. Latest version of winget-create errors out when trying to update manifest with these entries (only the installer entries from the manifest are shown here):

Installers:
- Architecture: x86
  Scope: user
  InstallerUrl: https://github.com/kiwix/kiwix-js-windows/releases/download/v2.0.9/Kiwix-JS-Electron-Setup-2.0.9-E.exe
  InstallerSha256: AFE82A7B77ADFD259B336BB0DFE85D88098CDB43DCC6C307E35D1922233EA8E7
  InstallerSwitches:
    Custom: /CURRENTUSER
- Architecture: x86
  Scope: machine
  InstallerUrl: https://github.com/kiwix/kiwix-js-windows/releases/download/v2.0.9/Kiwix-JS-Electron-Setup-2.0.9-E.exe
  InstallerSha256: AFE82A7B77ADFD259B336BB0DFE85D88098CDB43DCC6C307E35D1922233EA8E7
  InstallerSwitches:
    Custom: /ALLUSERS

This used to work, so it's a recent issue.

[Jaifroid]

NB, same error with two scopes and one installer is mentioned back in 2021 here: https://github.com/microsoft/winget-pkgs/issues/500#issuecomment-932892281. The version of winget-create I was using was even older, I think, and I only recently updated to the latest version, hitting this error each time I try to update that and similar manifests for my apps. I've been having to calculate the SHAs using PowerShell and update manifests manually, though I'll give https://github.com/vedantmgoyal2009/winget-releaser a go.

[Jaifroid]

@ryfu-mfst Thanks for picking this up. Just to note, that in my case it's not different architectures that are causing the winget-create issue, it is different installer scopes: Scope: user and Scope: machine. The architecture is the same in both cases (x86).

@Jaifroid, thanks for bringing this to my attention. Looks like this is a bug that I will need to fix to address the scenario where the same installerURL is being used for multiple architectures. Will work on a fix for this...

[iqfareez]

Well, I'm also getting this error but with manifests that have two entries for the SAME installer/architecture, due to scope user and scope machine. Latest version of winget-create errors out when trying to update manifest with these entries (only the installer entries from the manifest are shown here):

Installers:
- Architecture: x86
  Scope: user
  InstallerUrl: https://github.com/kiwix/kiwix-js-windows/releases/download/v2.0.9/Kiwix-JS-Electron-Setup-2.0.9-E.exe
  InstallerSha256: AFE82A7B77ADFD259B336BB0DFE85D88098CDB43DCC6C307E35D1922233EA8E7
  InstallerSwitches:
    Custom: /CURRENTUSER
- Architecture: x86
  Scope: machine
  InstallerUrl: https://github.com/kiwix/kiwix-js-windows/releases/download/v2.0.9/Kiwix-JS-Electron-Setup-2.0.9-E.exe
  InstallerSha256: AFE82A7B77ADFD259B336BB0DFE85D88098CDB43DCC6C307E35D1922233EA8E7
  InstallerSwitches:
    Custom: /ALLUSERS

This used to work, so it's a recent issue.

Same issue here. Workaround that maybe can work is to pass the --interactive flag to wingetcreate update <PackageName>. (But the drawbacks you can't use it in your CI pipeline)

[cderv]

I have the same issue. Related to https://github.com/microsoft/winget-create/issues/166 IMO

[Jaifroid]

The thing is, this used to work before September 2021, then an update broke it. Whichever dev is working on wingetcreate, I think this needs to be a priority. One of the main reasons to use wingetcreate is in automated build and publishing, but it's currently causing me to have to intervene manually (in a laborious way) each time I prepare a new release. I'm about to give up and just write an automated powershell script to grab the SHA and forcibly update the mainfest values, but this won't do any of the testing and validation that is a great benefit of wingetcreate.

[Jaifroid]

Is there any update on allowing wingetcreate to update manifests that have the same package listed for different scopes (per user and per machine)? It's currently unusable, as it errors out, saying that a manifest shouldn't have the same package listed twice. This is clearly a bug, because we don't need different packages for different scopes. Usually it's just a quesiton of changing an installer flag on the commandline. This used to work in wingetcreate, before September 2021. It should be an easy fix.