-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide Structured Data Format Options #1753
Comments
@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. |
Since my feature request was closed as a duplicate of this one, I wanted to add my example usages here: winget list -o csv | ConvertFrom-Csv | Where-Object Name -match Microsft | Sort-Object Name You could also support a List format that would not truncate text e.g.:
I would imagine the default |
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. |
Have you seen System.CommandLine? Or the dotnet CLI. 🤷♂️ |
Isn't the "PackageManagement" Powershell module a full-fledged package manager? Why didn't they just use that? |
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 cool I'll check out the module. Me and @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. |
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. |
@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. |
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. |
Will the COM API be stabilizing anytime soon? At least as used by the powershell module? |
@josh-hemphill yes, it's actually what the Microsoft Store and Intune have used to integrate with. |
We're in the process of updating the documentation for the COM API (both "in-process" and "out-of-process"). |
After trying out the new PowerShell module, I'm going to renew my request for raw JSON output. Many command line tools have such a feature. Give me JSON or XML, and I can handle the rest in PowerShell. As it stands now, the object output from the module is more convoluted than it needs to be. I'll be posting more issues. |
I second that. To be clear, both approaches should continue, the PowerShell module and the structured output. I'd prioritize PowerShell, which I believe is more common for Windows administration. |
Having caught up to this issue, what's in the new release, and the discussion in #2796, I would like to reiterate support for this issue for the following reasons. Regardless of anyone's preferences, Winget is and will always be a console app which must be able to run outside of a PowerShell host in order to function as a universal package installer. That means native PowerShell support (which I do want) has to happen outside of the executable, which I know the team has been working on. So, I propose let's keep this issue focused on winget.exe. Console apps which output data must always deal with the same sets of problems over and over again. What to display, how to format it, sorting, filtering -- the list is endless. This list HAS ALREADY BEEN SOLVED IN POWERSHELL. But -- that's a topic for another issue, another discussion. Most console apps outside of Windows, or prior to PowerShell's existence which faced this problem only had two paths to go down:
Pretty sure everyone here is already in the second camp. If it's easy to add CSV and/or JSON (these being the most obvious formats to support),I would vote to keep this issue open and work towards that. And if you already have an internal object representation that maps well to the output for a given object, just give us that in JSON and be done. For example, half the commands will output a single package, or an array of them. That's one object to worry about; do that and you've solved 80% of the automation use cases -- maybe more. If it's not easy, let us know. Speaking for myself, I'd then say close this issue, and let's help you get your COM-based API work for proper PowerShell support in good shape instead. (Proper means real .NET objects which avoid all the problems that @jdhitsolutions highlights in #2796 .) |
Wish to second this as well. I am currently working on a rust-based TUI app which should support various package managers, including winget, and currently parsing whatever winget gives you as output is absolutely unusable, as the tables do not even have proper delimiters where you can split. I just want to be able to call winget in a subprocess from my app and get proper parseable stdout, stderr and a sane exit code. |
Hey any updates? Parsing WinGet's current output is a nightmare, and I don't want to have to deal with PowerShell in my project |
Bumping because I'm running into an issue where |
We've published the Microsoft.WinGet.Client PowerShell module which provides structured data. For those who do not want to depend on PowerShell, WinGet has COM APIs that an application can use for integration as well. |
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. |
I would still love to see winget with a format option to output JSON. |
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 @denelon cloing this as 'completed' is a bit of a joke, because it's not solved. at all. |
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) |
Description of the new feature / enhancement
Short of adding native PowerShell support, it would be very helpful if a command-line
Winget upgrade
orwinget 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
The text was updated successfully, but these errors were encountered: