Feedback on Microsoft.WinGet.RestSource

[denelon]

This discussion topic was created to provide feedback on the PowerShell module for working with REST sources.

Note, this is an initial released designed to work with the reference implementation deployed to Azure. We still have additional work to make this support any valid REST API implementation.

[jedieaston]

I clicked report but you might be able to get it moving faster:

[doctordns]

Ahh - thanks for that! As I said, I kind of expected the first cmdlets to be ones I could use in place of winget.exe.

[denelon]

I'm one PR away from opening up the new repository.

[jantari]

Is the new repository up? I didn't find it by searching at least: https://github.com/orgs/microsoft/repositories?q=winget

[doctordns]

I have not see it yet, but @denelon might have more details.

But as there is so little progress on usable PowerShell cmdlets, I wonder whether it would not just be better to cancel cmdlets totally. Of course, that would mean giving up on the goal of having a fully functioning Packager Manager but with Chcolately, I am not sure there is really a need for yet another product (especially one that is not truly Enterprise ready).

[denelon]

We decided to keep the cmdlets in the winget-cli repository.

[denelon]

We've been talking about local options whether it's an emulated environment, or some kind of VM or container based solution, but it's still early in the discussion pre-design phase.

[doctordns]

I am confused. I am just an IT pro that wants winget cmdlets to install stuff from a MS Curated repository. Do I really need to have an azure account and create REST data stores just to install a package? I can use winget.exe without this stuff, so why does PowerShell cmdlets seem to need it (or why is such stuff your first priority)?

The first cmdlets should have been cmdlets that find and install packages from the MS curated repo, as well as list, remove, or update packages that are already installed. As a first step.

With no progress on cmdlets, I continue to be of the view that Winget is little more than a powertoy for developers and not a serious enterprise package manager platform. As ever, I am happy to be proven wrong.

[denelon]

No, you don't need an Azure account or create your own REST source. We've been working on some IT Pro based solutions. One of the areas is enterprises who wish to host their own source rather than use the Microsoft Store or the Windows Package Manager Community repository.

Building cmdlets requires a rich object model that the CLI doesn't provide. We've been refactoring the functional code into a COM API so the Windows Package Manager can simply be a client interfacing with the COM API, and PowerShell will interface with that same COM API.

[Gijsreyn]

Hi @denelon, I just stumbled on this discussion to give some small feedback on the just officially released PowerShell module Microsoft.WinGet.RestSource.

When looking at both the WinGetManifest.ps1 and Remove-WinGetManifest.ps1 scripts, I can see that the Version or PackageVersion is a string. Perhaps it would be better to use the [Version] attribute to be more strongly typed. It's in the small details.

[denelon]

The module was published as Microsoft.WinGet.RestSource at the PowerShell gallery, I'm going to update the discussion title.

[doctordns]

one great solution would be for the winget team to implement a [SemanticVersoin] class, use it here and submit it as a PR for .NET

[Gijsreyn]

@jantari, do you think the [System.Management.Automation.SemanticVersion] attribute would simply do the trick, as the module targets 7.4 anyway?

[jantari]

Thanks for teaching me about that, and you're right the RestSource module doesn't have to be compatible with 5.1 the way the WingetClient module has.

Imo it still wouldn't work because, again, manufacturers just do the weirdest things with their version numbers like e.g. adding underscores or using 5 numeric parts - both examples that are incompatible with both Version and SemanticVersion. Windows has allowed freeform strings for too long to take them back now.

[Gijsreyn]

Gotcha! You're right, I overlooked that part.

[Gijsreyn]

Hey @denelon, after going through the solution that is created by the New-WinGetSource cmdlet, I stumbled on the fact that it's using the function app host key to authenticate through APIM. Perhaps it would be an improvement to use MSI, instead of injecting a header. See screenshot below:

Note

It requires additional configuration to enable system or user-assigned managed identities.