- 
                Notifications
    
You must be signed in to change notification settings  - Fork 297
 
feat(completions): Update winget-completions.nu for winget v1.11.510 #1183
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
base: main
Are you sure you want to change the base?
Conversation
          
 I'm not a fan of having raw winget cli output. This is supposed to be a nushell script. if detect columns works great, as indicated in all this text, then it should be used to format the output in nushell tables.  | 
    
| 
           Hi @fdncred, Thanks a lot for the feedback! I really appreciate you taking the time to review this in detail. 
 I completely understand your concern. AI-generated code can sometimes miss the intention or lack quality, especially without sufficient human review. I admit that this PR was initially generated by AI, but I manually verified it by comparing the previous and current implementations. In this case, it was a very clear and well-defined change, so it was easy for AI to understand my intention: mapping help messages to completions. I’ve tested the new version on two of my own PCs, and in my main usage scenarios (such as  I hope this helps address your concern. 
 I agree that ideally, the output should be nicely formatted in Nushell tables. However, parsing raw winget CLI output is extremely difficult because it’s not machine-readable: the separators are inconsistent, and some cells may be empty, which breaks any structured parsing logic or makes it too complex. Microsoft’s PowerShell implementation faced the same issue. They avoid parsing the CLI output either. Their solution was to bypass the CLI entirely and instead call the underlying COM/WinRT interface directly. Given that limitation, I believe returning the raw CLI output is currently the most pragmatic and maintainable approach. If winget ever provides a structured output format in the future (e.g., JSON or XML), I’d be happy to revisit this and add proper Nushell formatting then. Thanks again for the constructive discussion!  
 
       | 
    
| 
           @fdncred kindly ping for your feedback.  | 
    
| 
           I understand your points about winget not supporting a structured output format, shame on them. But I'm not inclined to land a version of this that removes the nushell tables. Seems like regex could be used here to make the tables or maybe there's some other way based on how powershell does it?  | 
    
| 
           Hi @fdncred, Thanks for clarifying — I see the core issue now is whether this completion should keep parsing into Nushell tables. Let me show you why I was hesitant to say “let’s just regex it,” using the exact output shape from the screenshot I tested with.  
The data itself looks like a table, but it’s only visually aligned. In the screenshot the gaps between columns aren’t consistent. On the line with  Some rows contain values that “look like” other columns. The name  Some Version cells are not “plain versions”. On the  And all of this can change with terminal width. Because of all that, my takeaway is: we can write a regex that works on this screenshot, but we can’t write a simple, stable regex that works on “arbitrary winget output on arbitrary user machines” — which is what we want for completions. That’s also why I mentioned PowerShell earlier: Microsoft’s own PowerShell integration doesn’t try to parse the CLI text output either — they skip the CLI and talk directly to the COM/WinRT layer underneath, because that’s the only place where the data is actually structured. In other words, even the people closest to winget decided “parsing the pretty console output” is the wrong abstraction. So that’s the reasoning behind my proposal: in Nushell, unless we also go to a structured source (like PS did), returning the raw CLI output is the most honest and the least fragile thing we can do right now. If/when winget gives us JSON/XML, I’m 100% on board with tables.  | 
    
| 
           I understand your point. However, it seems like there's several ways to parse the results. 
 I use UniGetUI and it outputs to a grid as well. Not sure what it uses but it's open source too https://github.com/marticliment/UnigetUI The 3rd bullet above has a blog post on what the output looks like when Invoke-WinGetCommand is called too https://powershellisfun.com/2024/11/28/using-the-powershell-winget-module/  | 
    
| 
           Hi @fdncred, Thanks again for taking the time to dig deeper into this and for sending concrete references -- that’s super helpful context. On the third link (the PowerShell one): that’s exactly the implementation I’ve been referring to. Microsoft’s PowerShell module doesn’t try to parse the CLI text output either. It goes straight to the underlying COM/WinRT API so it can work with structured data. That design choice is, in my opinion, basically an admission from the source that “the pretty console output is not a stable contract,” so they avoid the parsing problem altogether. On the second link (the wingetui TypeScript code): this is precisely the approach I was saying doesn’t hold up generally. It treats “two or more spaces” as column separators. You can see it here: https://github.com/ynsmrtpc/wingetui/blob/86f35a4366bb95b121e7c78acc3fb03584695c79/electron/services/winget.ts#L744. That works as long as the output is nicely spaced and the names don’t contain “version-like” substrings, but it’s fragile in the exact cases I showed earlier (narrow terminals, long names, names containing version-ish strings, single-space gaps, etc.). On the first link (the C# one): it’s doing fixed-position substring slicing: https://github.com/baget/WingetUI/blob/a992b84b102c97a9524406811873eb41a69e53a4/Winget.cs#L46-L50. That can work if you control the environment, e.g. you run winget in a process that isn’t constrained by the user’s terminal width, or you know exactly what width you get back. But Nushell completions don’t have that guarantee. winget will adapt to the current terminal, so those fixed offsets can shift, which is the core reason I’ve been arguing “this isn’t a stable thing to parse” in this context. That’s why I landed on: for this PR, in this environment, returning the raw CLI output is the least fragile, most honest option right now. If we later get a structured output ( If you still feel strongly that the completion must emit tables no matter what, we can try to add a best-effort parser (basically the “2-spaces” approach) but I want to be explicit that it will be brittle across terminals/locales/longer names, which is the thing I’ve been trying to avoid. And honestly, if we forced a “best-effort” table parser here, I personally wouldn’t load that completion at all. It would introduce more trouble than convenience, just like the current implementation does. That’s really what I’m trying to avoid. Thanks again for pushing on it. I’ve already gone through these options and that’s why I took the more conservative route here.  | 
    
          
 Can you show me where this happens? I was thinking this line below is just calling winget and getting the output then parsing.  | 
    
| 
           @fdncred Good catch! I realize there might be some confusion here because the file you linked isn’t from the currently maintained PowerShell module. The file you linked does shell out to  
 So, to clarify: the current PowerShell module doesn’t parse the raw CLI output at all. It uses the COM/WinRT layer directly, which is how it can safely produce structured objects and formatted tables. Does that line up with your understanding?  | 
    
          
 Yes, it does. However, it doesn't answer whether similar nushell code could be used to parse the output. It looks pretty interesting to me since it's atypical from what I normally see parsing textual output.  | 
    
| 
           @fdncred Thanks for sticking with this. I think we’re finally looking at the same picture now. What I’m hearing is: 
 Where we still differ is how much we’re willing to trade correctness for convenience: 
 That’s why I was proposing a small sequencing change: 
 This way: 
 If that sounds acceptable, I’m happy to open a follow-up to track “best-effort tableization of winget output” and we can keep experimenting there. Thanks again for pushing on quality here. I do appreciate it.  | 
    
| 
           We need to find a better way. I'm fine with most things in this PR except removal of structured output.  | 
    
| 
           @fdncred I’ll bring back the structured/table output so we can keep this PR moving forward. That said, I still want to call out the screenshot I shared earlier: that exact output shape already breaks the kind of “looks-like-columns” parsing we’re talking about, and that’s on a normal machine with real data. So even if we keep the table step for now, I don’t think it’s a reliable abstraction, and I’d rather we treat it as “best effort, fragile” than “this is the right way to do winget in Nushell.” I’ll update the PR accordingly.  
 
       | 
    
fcaa3db    to
    8e45c8d      
    Compare
  
    | 
           can you provide the tabular winget cli output in the bottom screenshot as text?  | 
    
| 
           @fdncred My environment has changed, but I can provide you with another one. However, I was surprised to find that even on the same machine, it sometimes produces the correct output and sometimes doesn’t. I didn’t change the terminal width or do anything else. I just executed the command 3 times. Another case:  | 
    
| 
           BTW, I’ve updated the PR to add back the tablizing logic and also updated the PR description to match the change.  | 
    




Winget Completions Update Summary
Overview
Successfully updated the winget-completions.nu file for Windows Package Manager v1.11.510.
Changes Made
1. Gathered Complete Documentation
winget-help-dumps/folder for future reference2. Major Updates
New Commands Added
winget pin- Manage package pins (with subcommands: add, remove, list, reset)winget download- Downloads the installer from a given packagewinget configure- Configures the system into a desired state (mentioned but not fully implemented)winget repair- Repairs the selected package (mentioned but not fully implemented)winget dscv3- DSC v3 resource commands (mentioned but not fully implemented)Enhanced Existing Commands
All commands now include the full set of global options:
--wait- Prompts before exiting--logs/--open-logs- Open logs location--verbose/--verbose-logs- Enable verbose logging--nowarn/--ignore-warnings- Suppress warnings--disable-interactivity- Disable interactive prompts--proxy- Set proxy for execution--no-proxy- Disable proxy for executionNew Options in Install/Upgrade Commands
--architecture (-a)- Select architecture--installer-type- Select installer type--custom- Additional arguments for installer--ignore-security-hash- Ignore hash check failures--allow-reboot- Allow system reboots--skip-dependencies- Skip dependency processing--ignore-local-archive-malware-scan- Ignore malware scans--dependency-source- Source for dependencies--no-upgrade- Skip upgrades if already installed--authentication-mode- Authentication preference--authentication-account- Account for authentication--rename (-r)- Rename executable (portable)--uninstall-previous- Uninstall old version during upgradeEnhanced List/Search Commands
--cmd/--command- Filter by command--upgrade-available- Show only upgradable packages--unknown/--include-unknown- Include packages with unknown versions--pinned/--include-pinned- Include pinned packages--versions- Show available versionsEnhanced Uninstall Command
--product-code- Filter by product code--all/--all-versions- Uninstall all versions--purge- Delete all package files--preserve- Retain created filesSource Management Updates
--trust-leveloption for source add--explicitflag for source add3. Improved Completion Functions
Updated Completers
nu-complete winget sources- Lists available package sourcesnu-complete winget scope- user/machine scope optionsnu-complete winget locale- BCP47 locale codesnu-complete winget architecture- x86, x64, arm, arm64, neutralnu-complete winget installer-type- All installer typesnu-complete winget authentication-mode- silent, silentPreferred, interactivenu-complete winget source-type- Microsoft.PreIndexed.Package, Microsoft.Restnu-complete winget trust-level- none, trustedNew Completers
nu-complete winget installed packages- Caches installed packages for uninstall completions4. Syntax Improvements
@for attaching completers to type annotationswinget add,winget view,winget find, etc.)5. Documentation
6. Structured Output Restored
winget source list,winget search, andwinget listso they once again return Nu tables by default--rawescape hatch on each wrapper to expose the unparsed CLI output when desirednu-complete winget flagify,nu-complete winget trimLoadingSymbol, and thewinget upgradeshelper to support the parsing workflowTesting
Breaking Changes
None. Legacy structured output helpers have been restored; use the new
--rawswitch on each wrapper if you prefer the original CLI text.Recent Improvements (Based on Cargo/Eza Completions)
Code Quality Enhancements
Enhanced Documentation
@category package-managerannotations to all main commands@exampleannotations with practical use cases for key commands:winget install- 3 examples (by name, specific version, silent install)winget show- 2 examples (package info, available versions)winget search- 2 examples (basic search, exact ID search)winget list- 3 examples (all packages, upgrades, by source)winget upgrade- 3 examples (show upgrades, upgrade all, specific package)winget uninstall- 2 examples (by name, by ID)Improved Completion Functions
Better Code Organization
Notes
winget source list,winget search, andwinget listlayer defs on top to provide structured table output by default