AnyPackage and package providers

[marco-eckstein]

I noticed that WingetUI does something very similar to AnyPackage, a community project that supersedes Microsoft's deprecated PackageManagement (aka OneGet). However, unlike WinGetUI, AnyPackage is for the command line.

So naturally I am wondering why WingetUI does not use AnyPackage under the hood. This could potentially free up resources, so that WingetUI developers could concentrate on the UI.

I have also noticed that WingetUI does not seem to have a provider interface. All work that is necessary to support package managers like Chocolatey or Scoop apparently needs to be done in WingetUI itself. AnyPackage on the other hand has adopted the provider architecture from PackageManagement. Other teams can independently publish new providers. For PackageManagement, this has lead to a large number (currently 26) of package providers, including exotic ones like GistProvider which allows to treat GistHub Gists as packages. (Note that on the new multi-platform PowerShell, the number of package providers is much smaller (currently 8).)

I do not know whether AnyPackage could fulfill WingetUI's requirements. I think that at least some providers would need to be contributed, because while WingetUI can access the Microsoft Store, there is no dedicated AnyPackage provider for it - only via AnyPackage.WinGet there is limited support, but since WinGet itself does not have good Microsoft Store support, it cannot be good.

It is a pity that there are two unified package management interfaces (or meta package managers as I would call them), and none is strictly more capable than the other: WingetUI is not a command line tool and AnyPackage does not have a GUI.

[marticliment]

I don't think integration with AnyPackage will be a thing soon, but creating extensibility is a thing I have in mind.

[marco-eckstein]

Can you elaborate a bit on the reasons, please? I'm just curious. Also, if integration with AnyPackage is off the table, are there plans for making the WingetUI core accessible via a command line interface?

[marticliment]

I thnik there is no reason to implement a commandline since AnyPackage aready exists and does a great job at it. There is no need to invent again what already exists (+ would require tons of work).

Also, adding OneGet to WingetUI would only report duplicate packages, since most package managers are already available

[marco-eckstein]

Also, adding OneGet to WingetUI would only report duplicate packages, since most package managers are already available

I assume you mean AnyPackage, because OneGet is deprecated? In any case, I was not suggesting to support it as another package manager in addition to WinGet, Chocolatey etc., but to use it as the "engine" beneath the GUI. If AnyPackage is capable to offer all functionality that the GUI needs, that approach could actually save you a lot of work. And if some provider is missing for some package manager (e.g. Microsoft Store), you could implement it as a separate project - probably even reusing the code you have already written to connect WingetUI to that package manager.

As an end user, I don't care much. So this is not a request. It is just a suggestion for a potentially feasible WingetUI architecture overhaul that could distribute the work among more developers, without need for close collaboration.

[marticliment]

Or, I could just implement AnyPackage as another package manager, and let the user decide to use it or not. And then users can decide between appget and other managers, maybe?

[marco-eckstein]

With the currently available AnyPackage providers, I don't know if it would bring any advantage, but it would open up the opportunity for third-party developers to indirectly plug into WingetUI via new AnyPackage providers.

Not sure how you would deal with packages being listed multiple times then, e.g. by WinGet and by AnyPackage via the WinGet provider. On the other hand, WinGet is also somewhat of a meta package provider already (serving packages from both the WinGet repository and the Microsoft Store), so maybe you already have a strategy in place to deal with this kind of overlap.

I am not sure if it is worth the effort though. My main point was actually the potential to save work, not to cause more.