rami3l/pacaptr

[Feature Request] Add support for winget

luxus opened this issue ยท 9 comments

luxus commented

hello,
i wonder if there is support for the official windows package manager
https://docs.microsoft.com/en-us/windows/package-manager/winget/
i prefer it over scoop and choco

Thanks for making this feature request!

Actually, I have received the same request before, but at that time, it seemed that winget was not YET a full-featured package manager (it didn't even have uninstall)... That's why I decided to put it aside and wait.

When it reaches v1.0 milestone (maybe later this year?), I'll be glad to return to this issue. Thanks :)

luxus commented

winget got released 16 days ago as 1.0 and included uninstall and upgrade.
the cmds are pretty easy for winget (and I use windows mostly for gaming) so its not so important for me have it supported with pacaptr

https://github.com/microsoft/winget-cli/releases

telegram-cloud-photo-size-5-6235778398072974219-y

Maybe I should wait for a while before trying to implement this ๐Ÿค”
(I'm thinking about stable input/output pairs that I can put into CI, however according to what I've tried, winget uninstall Wget-1.11.4-1_is1 is currently the only right thing to do, which is clearly a no-go since it requires a specific version...)

luxus commented

nobody expect it would be easy hehe.. but great that you tried... maybe we have to wait :D

Was wondering if there's any update on this? winget should now be available on all installations of Windows 10/11.

@ptanmay143 Thanks a lot for the gentle ping!

I have to confess that even though I made this project explicitly with Windows users in mind, I have moved away from Windows for quite a while personally (a bit before winget reached v1.0) , and I do fear of being irresponsible adding a half-baked solution to the release.

However, winget did get more interesting to look at in the previous year as it has been rapidly maturing. For example the previous issue seems to be resolved.

With limited bandwidth due to personal reasons recently, it might take a bit more waiting before I can finally get back on investigating this possibility. However, I'm willing to guide anyone interested through the process of adding such support to pacaptr, #330 being a good example of it.

In short, the difficult part is to figure out how to perform the pacman operations could be mapped to subcommand invocations (to winget in this example) based on real life usages. I'll be glad if you're familiar enough with winget and are willing to figure that part out with me :)

I, on the other hand, have not used Arch Linux in quite a while. So, my memory is quite muddy in remembering all the pacman options. I'll list some mappings for commonly used operations. They are as follows:

  • winget install appx mapped to pacman -S appx (install using pkgname).
  • winget uninstall appx mapped to pacman -R appx (uninstall using pkgname).
  • winget source update mapped to pacman -Sy (repository update like in apt update).
  • winget upgrade appx mapped to pacman -Syu appx (upgrade using pkgname).
  • winget upgrade --all mapped to pacman -Syu (upgrade all packages).

Off the top of my head, a few mappings which I know I'm missing are querying for a package and displaying information about a package.

This documentation from Microsoft shows all the available commands in winget.
This ArchWiki page shows most of the common operations across major package managers.

Hope this will be helpful.

@ptanmay143 I've started playing around with my windows VM. So far the mapping should be quite straightforward:

  • winget is a .exe
  • No confirmation prompt, use pacaptr prompts all the time

  • Q generates a list of installed packages
  • Qc shows the changelog of a package
  • Qe lists packages installed explicitly (not as dependencies)
  • Qi displays local package information: name, version, description, etc
    • Yield to Si
  • Qii displays local packages which require X to be installed, aka local reverse dependencies
  • Qk verifies one or more packages
  • Ql displays files provided by local package
  • Qm lists packages that are installed but are not available in any installation source (anymore)
  • Qo queries the package which provides FILE
  • Qp queries a package supplied through a file supplied on the command line rather than an entry in the package management database
  • Qs searches locally installed package for names or descriptions
    • Yield to Q and grep
  • Qu lists packages which have an update available
  • R removes a single package, leaving all of its dependencies installed
  • Rn removes a package and skips the generation of configuration backup files
  • Rns removes a package and its dependencies which are not required by any other installed package, and skips the generation of configuration backup files
  • Rs removes a package and its dependencies which are not required by any other installed package, and not explicitly installed by the user
  • Rss removes a package and its dependencies which are not required by any other installed package
  • S installs one or more packages by name
  • Sc removes all the cached packages that are not currently installed, and the unused sync database
  • Scc removes all files from the cache.
  • Sccc (?)
  • Sg lists all packages belonging to the GROUP
  • Si displays remote package information: name, version, description, etc
  • Sii displays packages which require X to be installed, aka reverse dependencies
  • Sl displays a list of all packages in all installation sources that are handled by the packages management
  • Ss searches for package(s) by searching the expression in name, description, short description
  • Su updates outdated packages
  • Suy refreshes the local package database, then updates outdated packages
    • Yield to Sy and Su
  • Sw retrieves all packages from the server, but does not install/upgrade anything
  • Sy refreshes the local package database
  • U upgrades or adds package(s) to the system and installs the required dependencies from sync repositories

Does that seem okay to you?

@luxus @ptanmay143

It's very weird that winget is not a package manager currently avaiable in GitHub Actions, which means I won't be able to add CI tests for it without manually locking to a version like in actions/runner-images#910 (comment).


Update: It turns out that I have to install scoop to install winget (microsoft/winget-cli#1328 (comment))! It's not very idiomatic but I did so anyway :(