Repository navigation
Provide Structured Data Format Options #1753
Description
Description of the new feature / enhancement
Short of adding native PowerShell support, it would be very helpful if a command-line Winget upgrade or winget list had a format switch that would write output to a format like CSV, JSON, or even XML. That way I could run a native Winget command in a PowerShell function and more easily work with the output. Right now, parsing the native Winget output is a very, very tedious task.
Proposed technical implementation details
I'd like to run a command like this in PowerShell
winget upgrade --format json | Out-file upgrade.json
Activity
denelon commentedon Nov 30, 2021
Jeff Hicks (@jdhitsolutions) we are working on PowerShell cmdlets. We are also discussing adding a switch to provide JSON output via the COM interface to help with our own ability to support PowerShell pipelining. You can see some of the work in progress on my fork.
rkeithhill-keysight commentedon Oct 13, 2022
Since my feature request was closed as a duplicate of this one, I wanted to add my example usages here:
You could also support a List format that would not truncate text e.g.:
I would imagine the default
--output-formatwould beTableto match how winget displays by default.treestryder commentedon Oct 14, 2022
Seems odd, after all these years of Powershell, that any group at Microsoft would roll their own command-line parser and not pipe .Net objects to a built-in formater.
rkeithhill-keysight commentedon Oct 14, 2022
Have you seen System.CommandLine? Or the dotnet CLI. 🤷♂️
treestryder commentedon Nov 11, 2022
Isn't the "PackageManagement" Powershell module a full-fledged package manager? Why didn't they just use that?
halr9000 commentedon Dec 19, 2022
Any update on this issue? This is a serious accessibility issue for me. When you must use large terminal font sizes and lower display sizes like I do, this makes truncation an everyday problem. Listing, installing, upgrading, removing -- I always run into the dreaded "... "problem, and then have to do extra work to determine what the heck winget is trying to tell me. Sometimes, it's frustrating enough that I'll skip it and use the GUI. Which is a total fail in my book!
TIA
denelon commentedon Dec 21, 2022
Hal Rottenberg (@halr9000) we've just released a native PowerShell module. It provides structured output.
The CLI was designed to provide tabular output, but clearly that fails in the face of large fonts and lower display sizes. Would another formatting mechanism work better in your opinion?
halr9000 commentedon Dec 22, 2022
Demitrius Nelon (@denelon) cool I'll check out the module. Me and Jeff Hicks (@jdhitsolutions) go way back though, so if he's happy I'm sure I will be 😊
As long as it outputs objects like a native PS cmdlet would, that's what I need.
jdhitsolutions commentedon Dec 22, 2022
I'll pick a major nit here and comment that your PowerShell commands are Crescendo wrappers around the command line tools. This is no different in concept that what many of us have already done, albeit without Crescendo. The major problem has always been creating a structured object from the winget output, which is a challenge when culture comes into the picture. Now, I have to still try this module and look at the code, but if the module is doing nothing more than parsing text, that's not much progress and it will be fragile. That's why I have always asked for structured output like JSON. It is easy enough to build a PowerShell function wrapped around winget, but if you give me an option for raw JSON data, then we can write structured, and predictable, objects to the pipeline.
denelon commentedon Dec 22, 2022
Jeff Hicks (@jdhitsolutions) the initial cmdlets I wrote initially were based on Crescendo. Unfortunately, the differences between the CLI syntax and PowerShell approved nouns and verbs were a bit too much to overcome. My goal in writing them was to get feedback on the syntax, not to release them as any form of final solution.
These cmdlets are based on the COM API which is a rich object-based structure. I'm looking forward to everyone's feedback. I'm expecting the need to iterate some before publishing an initial release to the PowerShell gallery.
jdhitsolutions commentedon Dec 22, 2022
After looking at the latest code, I see a combination of .NET and Crescendo. I'd love to see this succeed, but so far haven't been able to test it. See issue #2795.
josh-hemphill commentedon Dec 22, 2022
Demitrius Nelon (@denelon)
Will the COM API be stabilizing anytime soon? At least as used by the powershell module?
A lot of the time I want structured output, it's for use in other applications, and I'd love to be able to rely on winget data without having to spawn shells. Even if it's left as mostly "undocumented", even just a few documented functions would be useful.
11 remaining items
giggio commentedon Mar 6, 2024
This has been discussed in this issue. The PowerShell module is incomplete and should not be the only approach. Not everyone uses PowerShell. Winget should be a good citizen in cli world, and making output difficult to parse is not doing that.
This is not that complicated, why is it being treated as such?
jdhitsolutions commentedon Mar 6, 2024
I would still love to see winget with a format option to output JSON.
markusdd commentedon Mar 6, 2024
agree with the takes before, very unsatisfying answer.
CLI tools with output that is not easily parseable (and hence not piepable) is very bad practice.
Powershell obejct stuff is irrelevant to almost anyone and it's incomplete, and using a COM api is shooting shotguns at flies.
And Demitrius Nelon (@denelon) cloing this as 'completed' is a bit of a joke, because it's not solved. at all.
TechStudent10 commentedon Mar 6, 2024
agreed with all the points provided
Providing a basic JSON output for each command would be way more preferred than a PowerShell API (because no one wants to integrate PowerShell into their program)
StefanoBalzarottiNozomi commentedon Oct 21, 2024
Where is the documentation of the winget COM api?
DrPepperBianco commentedon Jan 18, 2025
The PowerShell Module is not an adequate replacement for a simple csv output!
First of all, the PowerShell Module won’t even install automatically, I had to copy it by hand into the PowerShell Module folder. [It seems there is a cmdlet without a '-' in the name, which the installer absolutely refuses.]
Then simple things, like "winget upgrade --include-pinned" is seemingly not possible with the powershell module.
I vote to reopen the issue.
JeffMill commentedon Jan 18, 2025
https://github.com/microsoft/winget-cli/blob/master/doc/specs/%23888%20-%20Com%20Api.md
however, good luck trying to figure out how to call these from PowerShell, or even just how to do the equivalent of "winget list"
AltitudeApps commentedon Feb 17, 2025
I agree with the need for both JSON and CSV output, as well as simply providing arbitrarily wide text output which can be redirected to a file. (mentioned here: #1653)
The original design philosophy of PowerShell included the ability to flexibly integrate other text-based command line tools seamlessly. Using PowerShell modules and .NET objects everywhere is NOT "the PowerShell way", it is just part of the PowerShell way.
A bespoke PowerShell module seems goofy when the winget CLI already does everything that I need it to do. Almost everything, that is. The winget CLI provides for all my needs, as long as I'm sitting in front of the console, watching what's printed after each command. I can widen my terminal and get full output. But try to redirect the perfectly good output to a file? Winget deliberately defeats me by truncating the strings, and now I discover that the project defies user requests to provide some sort of simple text output, which we could then pipe into whatever other tooling we might be needing to interact with.
Another scenario: sometimes I need to run
wingetin acmd.exesession in a legacy console host. For instance, when I want to upgrade Windows Terminal and/or PowerShell 7.x itself. It makes things much less confusing when the items I'm upgrading aren't running at all.Consider this a huge vote to reopen the issue!
rkeithhill commentedon Feb 18, 2025
For an example of how another package manager has implemented this see: https://docs.conan.io/2/reference/commands.html#command-formatters
There's an example just above this section:
This is all folks are asking for here. BTW the formats supported by Conan are:
JeffMill commentedon Feb 18, 2025
Keith Hill (@rkeithhill) Microsoft's own az-cli does the same.
DrPepperBianco commentedon May 5, 2025
Hi, the issue is set as closed, but as far as I can tell, there is still no option for structured output.
GoTo-Menyus777 commentedon May 16, 2025
Hi Demitrius Nelon (@denelon) !
Could you give us some insights on why this issue was closed?
I have read numerous issues linked to this discussion but I don't see the issue as resolved since there is still no option for structured output. In another thread I saw that winget target audience is based on 👍 and this issue has quite an audience now ^^
rkeithhill commentedon May 18, 2025
Having implemented a few C++-based CLI utilities that provide this feature i.e.
--format [csv | list | json | table], it seems like an easy ask. 🤷♂️mamoreau-devolutions commentedon Apr 5, 2026
Why was this issue closed? This is still something needed - to alternative is to force the output language to English to make it easier to parse, but having YAML or JSON output would obviously be a lot more reliable: #3581