PowerShell Command Output Needs Work

[jdhitsolutions]

So I finally got the PowerShell module working. I know it is alpha, which is why I'm bringing this up now. Object output needs to be more PowerShell-like. First glance, this looks good.

Until I try what most PowerShell users would try.

Ok. I get it. You have a format file to handle output from complex object. I can work with that.

I guess not. The NativeObject property is of no value to an IT Pro or end-user.

Command output should be a rich object, like system.diagnostics.process with the majority of properties "at the top". Your object is burying what the user wants to work with and makes this more complicated than it needs to be. Again, if Winget could return raw JSON, this would be so much easier than the COM object. I can't help but feel this approach is overkill.

[jdhitsolutions]

Here's another example of where the object fails.

and this:

These break from expected PowerShell behaviors.

[whitTech]

The two examples provided here appear to be identical.

[jdhitsolutions]

Oops. I must have copied the wrong screen shot. I think this is what I meant to post.

[whitTech]

Oh wow. No output is definitely a concerning level of broken. I might suggest editing the parent comment to include the corrected screenshot so it gets the visibility it deserves.

Thanks for performing this important functionality validation, Jeff!

[jdhitsolutions]

This tells me you aren't writing a valid PowerShell object to the pipeline.

[treestryder]

I'd rather see a valid Powershell .Net object, than JSON. Which could then be easily converted to JSON.
Find-WinGetPackage terminal | ConvertTo-Json

[jdhitsolutions]

I'm only suggesting JSON as a way to create a .NET object, even if it is a PSCustomObject. The problem is the convoluted nature of the COM object and there is different output from Find-WingetGetPackage and Get-WingetPackage. I would argue the object output should be identical. But even if it is different I expect to run a typical PowerShell command like:

Find-WingetPackage git | Sort name | Select name,Version

[jdhitsolutions]

I'd be happy with a traditional .NET object, It isn't here yet based on my testing.

[jdhitsolutions]

I think the Winget teams must answer a key design question: who is the target audience for the PowerShell module? I always tell my students, you need to consider who will be using your PowerShell commands? What are their expectations? What are the like use case scenarios you need to plan for? Answers to these questions help guide you on the choice of parameters, object property names, or whether you use parameter binding to name a few things.

[jdhitsolutions]

I do a lot of this with my module https://github.com/jdhitsolutions/WingetTools, but I have to parse text from winget output which is ugly, fragile, and next to impossible when other UI cultures come into play.

BTW, there are 14K downloads of my module, so there is a bigger need than you realize.

[denelon]

I think there are going to be some subtle distinctions between metadata in a "manifest" and a "package". We will need to look through all of them to make the determination and figure out the right way to reason about things like "architecture" and "scope". The conceptual differences between what variations of a package are available vs. what is installed can be quite tricky to reason about, and in some cases with limited data, we aren't left with 100% confidence.

What did you use to generate the list of properties?

Why "PublisherHome" as opposed to "Publisher URL"?

[jdhitsolutions]

PublisherURL is just as fine. That's the kind of thing where it is easy to add a property alias. But let't not get ahead of ourselves. And I have no problem in making a distinction between a manifest and a package. But know that many of the property names are identical and the distinction is likely to be lost on many users. PowerShell has a long history of abstracting the sausage-making. That's why you have to think about who is going to use your commands and how. Most users won't care. They are thinking about a "winget package" which may be abstracted from the manifest and package.

Personally, I think you can make your life easier by focusing on a composite object. Otherwise, you need to make your commands very clear that these commands get manifest information about packages you might install, and these commands show you what is installed now.

[whitTech]

The target audience is represented by the group of users who added their 👍 to:

We're excited to engage and see how users are wanting to use the product.

EDIT: Misunderstood the location of the engagement. Carry on.

In any case, I just want to thank you very much for your work thus far, @denelon. While I agree with Jeff that there remains a lot to do to make this a first class Powershell module, this is fantastic progress. Looking forward to using it (lots!).

[halr9000]

I think the Winget teams must answer a key design question: who is the target audience for the PowerShell module?

Let's quote the manifesto for @denelon benefit:

[https://www.jsnover.com/blog/2011/10/01/monad-manifesto/]:

Problem
Windows has simple GUI administrative tools for basic users (Control Panel, MMC, etc). Windows also
has a rich set of languages, APIs and object models for advanced systems programmers (C, C++, C#,
WMI, Win32, .Net, etc). What is missing is the vital middle – administrator-oriented composable tools to
type commands and automate management. The vital middle is typically addressed by scripting
languages.

Also check out the visualization.

In this case, the COM object and its interface is meant for systems programmers. Please don't expose that in powershell -- it misses the point and audience. Instead go higher level and orient to a task based workflow and interface. Give us something composeable.

[jantari]

EDIT: Ignore, I put what I originally posted here into a proper issue: #2799

[denelon]

Yes, I would prefer smaller more discrete Issues. That makes it a bit easier to "complete" them within a single PR.

[jantari]

Totally makes sense, I filed #2799

[treestryder]

I knew I recognized that name, @jdhitsolutions . It must be hard to teach PowerShell Toolmaking in a Month of Lunches through posts on GitHub issues. 😉

[jdhitsolutions]

Ha! I have been constantly teaching this stuff since 2006, seemingly everywhere. 😄

[treestryder]

Why was the package manager already built into Windows, the PackageManagement Powershell provider, not used? Is WinGet that much better than OneGet? Was it forgotten? Do folks not realize Powershell is .Net, plus an amazing a command-line API?

[jdhitsolutions]

I think that module served a different need than winget. The PackageManagement module was focused on Nuget packages and I don't think winget has that same focus. I think there were other design considerations for winget early on which is why PowerShell support is only now getting attention.

[denelon]

TLDR;
There were environments that did not have PowerShell.

Discussed at:

• Add Native PowerShell Support #221

[jdhitsolutions]

In PowerShell context, the package is a module when it comes to the PackageManagement module.

[jdhitsolutions]

It doesn't matter now, but the idea that "there were environments without PowerShell" doesn't make sense. Winget, from what I can tell, only works on Windows machines and from a command prompt. Windows PowerShell has shipped with every version of Windows for years, especially desktops. It has been a while, but I suppose there might have been older versions of Windows Server that didn't ship with PowerShell out-of- the-box, but I can't imagine those systems were a target for winget.

And even if there was a requirement for Windows PowerShell 5.1, older systems should have been able to upgrade. But this is all old news and I'm sure there have been changes to the Winget product team so the best we can do is soldier on from here.

[sba923]

Can't use the CatalogPackage "workaround" here:

[sba923]

Can't use the CatalogPackage "workaround" here:

@denelon I'd like to provide feedback on that first implementation, but without this .CatalogPackage trick I fear there's not much I can do...

[denelon]

@ryfu-msft has been working on improving the PowerShell implementation and fixing the bugs. I need to think about how we can tag issues specific to PowerShell (I did add a PowerShell tag) or the winget.exe CLI for issues that really only affect one or the other. We're going to work on releasing preview builds a bit more frequently as we work through the early PowerShell implementation.

[sba923]

Good. I'll probably wait 'til the next preview then.

[sba923]

Good. I'll probably wait 'til the next preview then.

Problem's still there with v1.5.101-preview

[denelon]

@ryfu-msft is working on the improvements to the objects returned.

• Use C# wrapper objects for PowerShell cmdlet output #2871 (comment)

[sba923]

Great! Looking forward to the next preview with those improvements.

[sba923]

I'm experimenting with 1.5.441-preview's cmdlets: https://github.com/microsoft/winget-cli/releases/download/v1.5.441-preview/Microsoft.WinGet.Client-PSModule.zip.

I'm still lured by this:

which seems to suggest one can do:

get-wingetpackage | ? { $_.Available -ne '' }

@ryfu-msft suggests at #3069 (comment) to use this instead:

get-wingetpackage | ? { $_.AvailableVersions -ne '' }

But this doesnt' seem to produce the expected results either:

Nor does

get-wingetpackage | ? { $_.AvailableVersions -ne $null }

[jantari]

Yea, the "Available" column is still very confusing. First you have to know that there is no object property called "Available" at all, it's just created during formatting. And then the value of "Available" is set like this:

if ($_.IsUpdateAvailable) { $_.AvailableVersions[0] }

which is why it appears either empty when IsUpdateAvailable is false or as the latest available version when it is true because AvailableVersions is a sorted array of strings in which the first element is the latest available version.

To do what you want and show all packages for which an update is available, try:

Get-WinGetPackage | Where-Object IsUpdateAvailable

Imo the "Available" column should either just be removed entirely (we can check IsUpdateAvailable and AvailableVersions[0] ourselves) or it should be introduced as a real property of type string. It would either contain the same as AvailableVersions[0] or be an empty string. Since empty strings evaluate to false in PowerShell we could still test against it like:

# This code is hypothetical, doesn't work today
Get-WinGetPackage | Where-Object Available

It wouldn't be strictly neccessary but it would work intuitively and somewhat resemble the output of the DOS CLI.

[halr9000]

Yeah, ideally we could avoid violating the principle of least surprise here by having the formatted output align to the property names returned by the object. This can be achieved a few ways.

AliasProperty would help here! Get-Process & System.Diagnostics.Process is a great pattern that's existed since the beginning of time/powershell:

PS > ps | sort ws | select -last 5

 NPM(K)    PM(M)      WS(M)     CPU(s)      Id  SI ProcessName
 ------    -----      -----     ------      --  -- -----------
     92   600.01     288.36     170.48   16496   1 chrome
     28   451.29     344.76      26.78    6808   1 chrome
     75   373.59     394.10     346.11   17172   1 chrome
    374 …,219.02     662.60     108.59    3580   1 python
      0     5.21   1,810.10       0.00    2068   0 Memory Compression

PS > ps | gm work*,ws

   TypeName: System.Diagnostics.Process

Name         MemberType    Definition
----         ----------    ----------
WorkingSet   Property      int WorkingSet {get;}
WorkingSet64 Property      long WorkingSet64 {get;}
WS           AliasProperty WS = WorkingSet64

P.S. I would suggest not using space in column names during formatting. It's just gonna end in frustration every time. Nobody wants to type $.("Property Name"), even if it were a real property!

[sba923]

I know about the fact PowerShell does support displaying data in a way that's not a 1:1 match with the actual properties (I've been bitten e.g. by Get-PSDrive's Root vs. DisplayRoot) but IMVHO that sort of works against the "easy discoverability" of properties.

True, one can learn from:

PS> get-wingetpackage | gm

   TypeName: Microsoft.WinGet.Client.PSObjects.InstalledCatalogPackage

Name                  MemberType Definition
----                  ---------- ----------
CheckInstalledStatus  Method     string CheckInstalledStatus()
Equals                Method     bool Equals(System.Object obj)
GetHashCode           Method     int GetHashCode()
GetPackageVersionInfo Method     Microsoft.WinGet.Client.PSObjects.PackageVersionInfo GetPackageVersionInfo(string version)
GetType               Method     type GetType()
ToString              Method     string ToString()
AvailableVersions     Property   string[] AvailableVersions {get;}
Id                    Property   string Id {get;}
IsUpdateAvailable     Property   bool IsUpdateAvailable {get;}
Name                  Property   string Name {get;}
Source                Property   string Source {get;}
Version               Property   string Version {get;}

but for some reason that always comes after I've hit some "unexpected behavior."

We need to find the right balance...