Arguments cannot be put in any order during `wingetcreate update`

[jedieaston]

Brief description of your issue

You have to use the arguments passed to wingetcreate update in a specific order or you get an error, which isn't reflected in the documentation.

Steps to reproduce

1. Decide you want to update a manifest.
2. Run wingetcreate update and look at the options you have to pass (note that --version is listed before --urls in that help section).
3. Decide to do it that way, and run something like wingetcreate update -v 5.3.2 -u https://d13g8g4x8s9rc1.cloudfront.net/downloads/files/cdn/ti-nspire/5.3.2/TINspireCXStudentSoftware-5.3.2.129.exe TexasInstruments.TI-Nspire
4. Become confused as it doesn't work even though it should since you passed valid arguments.

Expected behavior

You get a manifest that is ready to be committed or used locally.

Actual behavior

You get an error stating "A required value not bound to option name is missing.", even though according to the help, you've bound all of the options you needed to, just in a different order.

Environment

Windows Package Manager Manifest Creator v0.4.1.1
Any other software?
Microsoft Solitaire Collection version 4.10.7290.0.

[Jaifroid]

I don't know if this is the same issue, but having updated to the latest version of wingetcreate, I'm now finding I can't script wingetcreate, as it is throwing errors, or asking for parameters I already include on the commandline. This always used to work in PowerShell:

& wingetcreate.exe update -i $package_id -v "$winget_version" -u $package_url -s $true -t $github_token

Now, when I run that in a script, with all values correctly set in the variables, I invariably get:

The following unbound argument(s) were detected: "true"
Please check and verify the usage of this command by passing in the --help flag.

If I remove -s $true, then it seems to make a bit more progress, as below, but then it stops and asks for the installer URL, even though it's clearly been included on the commandline...

Updating 1 of 1 installers:
Platform:
- Windows.Universal
MinimumOSVersion: 10.0.10240.0
Architecture: neutral
InstallerType: msix
InstallerUrl: https://github.com/kiwix/kiwix-js-windows/releases/download/v1.7.4-WikiMed/KiwixWebAppWikiMed_1.7.4.0_AnyCPU.appxbundle
InstallerSha256: 70723034D5FDD491EF86B92BEC767D1499302600984FBAD861E25A93D47033CC
SignatureSha256: 752A9638193CA3B6240F492A4A9619F0E157E952959D8BC879C07BD282C2813B
PackageFamilyName: Kiwix.WikiMed_qwjmsdmcnwx12

 What is the new installer url?:

As I say, the exact same script worked until I updated wingetcreate.

@denelon If this is a separate issue, please let me know and I'll create one.

[Jaifroid]

OK, I was able to get the script to run and successfully submit a manifest to the repository with the following line:

& wingetcreate.exe update $package_id -u $package_url -v "$winget_version" -s -t $github_token

Three remarks:

• The -s switch no longer accepts a Boolean value, so the documentation is wrong. It is simply a switch, if present it will submit, if not, it will do it interactively. Documentation still says it takes a Boolean, and it used to accept a Boolean
• The -i switch, which used to be the switch to indicate that what follows is an identifier, now no longer works, and breaks parsing of later switches. There should have been a deprecation period for this switch if it was removed, with a flag to warn developers to change their syntax
• Putting switches in a different order also seemed to cause wingetcreate to ask for the URL even though it is included with the -u switch. However, I can't be 100% sure that this was not a symptom of one of the above two points rather than the switch order. I can't experiment again now, because I have submitted the updated manifest.

[ryfu-msft]

Hey @jedieaston,

After looking into this, the reason why your arguments didn't work is because you put the directly after the argument for --urls. Since Winget-Create now handles multiple installer URLs, it thinks that the packageIdentifier you provided is another installer URL, hence why its showing that you have a missing required option error. The help text is confusing as it really should indicate that the should come first since its a positional argument.

If you have any suggestions on how to better handle multiple inputs for a single argument so that it doesn't get confused with a positional argument, we'd be open to suggestions. Thanks for bringing this issue to our attention.

[jedieaston]

Some CLI apps have you pass an argument multiple times if you want to send multiple values, for instance to add multiple environment variables when running a docker container, you do docker run --e foo=bar -e second=value... (where -e adds an environment variable). They don't expect multiple values after a space to be connected.

Is that something easy to do with the command line library you're using? Maybe that would make more sense for the user and for writing error messages.