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 microsoft/winget-pkgs#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: microsoft/winget-pkgs#500 (comment). 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 #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.

[jakopo87]

I'm having the same problem trying to update the package "TheDocumentFoundation.LibreOffice.HelpPack" to a new version and adding installers for other locales.

[tikkanz]

Having the same problem reported above by @Jaifroid updating the package Jsoftware.J.9.4 with 2 installer entries (both the same .exe) for machine & user scopes. Using the tool interactively works OK but isn't a solution for CI.
Any idea on the likely timeframe for this to be fixed?

[mdanish-kh]

@tikkanz @Jaifroid WinGet-Create 1.2.6.0 has support now for updating installers with different scopes. The following syntax can be used for update command now:

wingetcreate update <PackageId> --version <PackageVersion> --urls "<InstallerUrl1>|<arch>|<scope>" "<InstallerUrl2>|<arch>|<scope>"...

[mdanish-kh]

cc @denelon Resolved in WinGet-Create 1.2.6.0

[Jaifroid]

@mdanish-kh @denelon Thanks for the update and the advice to use overrides. I've now tested this, and although the overrides work, I do not consider this issue to be fully fixed for my use case. Wingetcreate, with overrides for per user and per machine on the same bundle or executable, downloads the exact same file twice.

Since I am frequently (at least twice a month) validating and submitting manifests for executables of 1GB and 1.6GB, this is very unfortunate, and definitely not necessary. Wingetcreate should check the URL, and not process identical URLs twice, as it has already worked out the hash.

The commandline I'm useing is:

wingetcreate.exe update <AppID> -v 2.5.0-E -u "<URL>|x86|machine" "<URL>|x86|user" -s -t *********

The <URL> here is identical. I am simply tying to get wingetcreate to update a manifest that has two scopes for one bundle. This used to work fantastically in an earlier version of wingetcreate. Unfortunately, this behaviour means I still can't use wingetcreate, which is a shame.

If you think it's best to open a new issue, I'll be happy to do so.

[mdanish-kh]

@Jaifroid I can definitely see how that's annoying. The request is being tracked here

• Do not re-download existing files #312

Edit: cc @Jaifroid Resolved in winget-create 1.2.7.0

[stevapple]

I don't think the issue is really resolved. It's still impossible to add or remove an installer option using wingetcreate update.

[mdanish-kh]

@stevapple The original issue was more related to the fact that the PR creation failed even when matching the number of URLs in the previous manifest

Your request is being partially tracked in #351 (request for an option like --add to add additional installers). There isn't one for remove since that doesn't seem to be popular use case. You can create an issue for that explaining your use case for the command

[stevapple]

@mdanish-kh Thanks for pointing out! Maybe this issue can have a new title to more accurately reflect the status quo?