Gaps between the Windows Package Manager Manifest Creator and YamlCreate.ps1

[denelon]

I'd like to get a list of the gaps between YamlCreate.ps1 and the Windows Package Manager Manifest Creator.

We've been discussing using the Windows Package Manager Manifest Creator in the Windows Package Manager Community App Repository for manifest automation scenarios. We will also be looking at PowerShell module/cmdlets for the Windows Package Manager Manifest Creator. I know some of the scenarios related to moderation are a bit different than the target audience for the Windows Package Manager Manifest Creator so I'd like to separately call those out.

I'm thinking a bit longer term about how we might pull the solution from @vedantmgoyal2009 into the winget-pkgs repository as well. Some of the current gaps are the key names, and possibly some of the mechanics. The goal would be to have an automated solution for keeping manifests current for packages where we can detect a new version using the Windows Package Manager Manifest Creator. We still prefer publishers submitting manifests as a part of their CI/CD toolchains, but this would help for those packages not quite ready to do that yet.

In order to have that work well, we need to know what kinds of gaps exist between the two tools. @Trenly I don't see a need to eliminate YamlCreate.ps1 or SandboxTest.ps1, but I'd like to be able to get to parity and consider an "interactive test" capability in the Windows Package Manager Manifest Creator and associated PowerShell cmdlets.

I'm also mentioning our moderators here as they are the predominant users.
@ImJoakim
@ItzLevvie
@jedieaston
@KaranKad
@OfficialEsco
@quhxl

[Trenly]

I know that currently YamlCreate.ps1 doesn't support automatic URL matching or passing URL's in through command line parameters. I believe that Vedant has partially implemented this in his automation, but only to the extent that they can be passed in through the command line, assuming the order of the installers is known.

YamlCreate doesn't support automatic detection of the package version, but I was starting to look at how that could potentially be implemented.

Other gaps are the MinimumOSVersion and dependencies, but I've also been looking at putting these into YamlCreate, as it wouldn't be too difficult.

---

I know this may be a little off topic, but the primary reason why I don't like wingetcreate is the menu based navigation. It makes it more time consuming to add all of the metadata rather than being able to skip it by pressing enter, specifically for the installers, at least in my own opinion

I personally would love to see more functionality, and have been trying to learn C# a little better to be able to contribute over at winget-create. I think improvements can be made on both ends, and if we can find a way to bring them together to create the best possible solution, I'd be happy to help

[vedantmgoyal9]

• for "update" scenarios, these things can be considered:

@felipecrs I have already tried to use wingetcreate for auto-updating manifests, but there are some things that need to be improved:
- when running `wingetcreate update`, it should automatically detect the new version, instead of updating the installer URL in the latest available manifest and in case of generating a new version manifest, we need to pass additional parameter `--version`
- the logic for matching installer architecture and type should be improved because it mostly gives errors:
   
Each new installer URL must have a single match to an existing installer based on installer type and architecture. The following installers failed to match an existing installer:
Multiple matches found for X86 Nullsoft installer detected from the url: https://github.com/IrosTheBeggar/mStream/releases/download/v5.4.3/mStream-Server-Setup-5.4.3.exe

- the number of InstallerUrls should be counted as 1 where there are two same URLs but the different scopes and installer flags.<be> for e.g. in case of Nullsoft Installer where they have two flags:<br>1. `Scope: user` and the flag is `/CURRENTUSER`<br>2. `Scope: machine` and the flag is `/ALLUSERS`

I'm sure wingetcreate will be much more powerful in the near future but till then I am using YamlCreate.ps1 to update packages that are shipped through GitHub Releases or have an API kind of thing where we can check periodically if a new version is available and update the manifests.

Originally posted by @vedantmgoyal2009 in microsoft/winget-pkgs#500 (comment)

• Prompt for "all" or "as many as" manifest fields. I tried to pop into some issues/discussions over the repo for a citation, but it's taking time. However, I remember someone said that "he likes YamlCreate because it prompts for more fields than wingetcreate".

---

I believe that Vedant has partially implemented this in his automation, but only to the extent that they can be passed in through the command line, assuming the order of the installers is known.

Yes; I pass the URLs and sort them (https://github.com/vedantmgoyal2009/winget-pkgs-automation/blob/main/scripts/YamlCreate.ps1#L784-L785).

Also, Trenly/winget-pkgs#28 has not been implemented yet, so when there are two identical InstallerUrls (as in the case of difference Scope/InstallerSwitches), I use the previous InstallerUrl for the next iteration (https://github.com/vedantmgoyal2009/winget-pkgs-automation/blob/main/scripts/YamlCreate.ps1#L807-L814).

[vedantmgoyal9]

One more thing: wingetcreate should automatically prompt the user to test the manifest in Windows Sandbox if it has been already enabled by the user or if not enabled, print something like:
"We recommend enabling Windows Sandbox using {command} so that wingetcreate can automatically test the manifest for you to eliminate the chances of errors during manifest validation performed before the PR is merged."

[jedieaston]

Sandbox in its current configuration isn't a great solution to the testing problem. You have to be on Windows client (no server version has the same functionality) and it's not on home.

I think we should investigate using normal containers for this. No graphics (why?) but winget behaves otherwise correctly inside a container.

[Masamune3210]

Another issue with using Sandbox is the fact that it loses its contents on exit, so a lot of setup has to be done each time you want to test a manifest change. I just use a VM with snapshotting ability so I can roll back to before the test to have a clean slate for the next time.