Ansible module to support the Windows package manager (winget)

[JamieMagee]

SUMMARY

I think that Ansible should support the Windows package manager, announced at Build 2020.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

win_winget

ADDITIONAL INFORMATION

- name: Install PowerToys
  win_winget:
    name: Microsoft.PowerToys

References:

• https://docs.microsoft.com/en-gb/windows/package-manager/
• https://github.com/microsoft/winget-pkgs
• https://github.com/microsoft/winget-cli

[nobilisgkill4]

Totally agree on that.

Ansible should natively use winget not choco. For linux distros the vendors packagemanger is also used for a good reason as default.

[DoTheEvo]

The ansible team did not make module for winget for two years? I guess windows as use case for ansible is not taken very seriously.

[davetapley]

Assuming most people are using Ansible to manage Windows Server instances then be aware that (source):

The client requires Windows 10 1809 (build 17763) or later at this time. Windows Server 2019 is not supported as the Microsoft Store is not available nor are updated dependencies. It may be possible to install on Windows Server 2022, this should be considered experimental (not supported), and requires dependencies to be manually installed as well.

See also:

• Missing winget.exe on server 2019 install microsoft/winget-cli#1954

---

And then there's also this (still open at time of writing):

• Doesn't run under WinRM microsoft/winget-cli#256

---

In light of these I think Chocolatey should remain best practice until / unless winget comes to Server officially and that WinRM issue is resolved.

[JamieMagee]

There's a discussion that is currently tracking all the open issues that need to be resolved for winget support on Windows Server 2022: microsoft/winget-cli#2361

[jborean93]

Ansible doesn't really have a best practice when it comes to a package manager, it just exposes what is already there and currently there's a win_chocolatey and win_scoop module. Talking about Ansible natively using a package manager is also a bit of a misnomer, we don't natively use any package manager. Some docs might refer to certain tools but that's mostly a historical thing and people are free to submit doc changes to mention other tools that are available.

There's nothing stopping anyone from writing their own module for winget but there are two problems:

• We only test against Windows Server and not the desktop editions - so until the above two comments are somewhat resolved this makes it hard to include here

Add that to the reported issues around running on WinRM and the lack of a PowerShell wrapper making it easier to work with programatically makes it hard for us to really expose this as a wrapper. I'm sure there is work being put into it by the Winget team and maybe some of my assumptions are wrong but this is just how I see the landscape as it is today.

• This collection has stopped accepting new module submissions https://github.com/ansible-collections/community.windows#contributing-to-this-collection

This is not to say we won't look at PRs for bugfixes or new features to existing modules, we just don't have the capacity to accept new modules. Each new module adds even more work for myself to maintain and in reality we need to stop using this collection as a general catch all and to start encouraging more people to use their own collections and making it eaiser for others to use them.

Until a time when we revisit the no new modules policy to this collection there's not much else we can do here so I'm going to close this issue.

[SimHeb]

Might become relevant again since Microsoft recently announced that Windows Server 2025 will receive winget as a package manager: https://techcommunity.microsoft.com/t5/itops-talk-blog/windows-server-summit-wrap-up/ba-p/4109224

[mcexit]

Something else to consider here is that winget (not Ansible) already has an official PowerShell module, but needs to be installed. Most Ansible Windows modules rely on PowerShell, so it would just be a matter of someone creating an Ansible module that checks/downloads the winget PowerShell module and then adds the desired functionality.

Scoop and Chocolatey, while they may still be actively maintained, are not really the way forward in terms of utilizing the tools recommended by Microsoft, and have limited value at this point since winget now has more features.

It seems silly that Ansible lacks support for the official Windows package manager, but continues to maintain tools that would be considered legacy. Can't Red Hat dedicated some resources for a developer to spend like one day to create an official winget module?

[jborean93]

Scoop and Chocolatey, while they may still be actively maintained, are not really the way forward in terms of utilizing the tools recommended by Microsoft, and have limited value at this point since winget now has more features.

Just because these products aren't from Microsoft doesn't make them any less relevant. Each approach the problem of package management on Windows in different ways. Each are valid and fit their own use case with their own advantages and disadvantages.

It seems silly that Ansible lacks support for the official Windows package manager, but continues to maintain tools that would be considered legacy

We don't maintain any of them. Chocolatey maintain win_chocolatey in their own collection. The win_scoop module is here in this collection but it is maintained by the community whenever someone submits a PR.

Can't Red Hat dedicated some resources for a developer to spend like one day to create an official winget module?

I wish it could be done in a day but the time and effort it takes to create a supported module is more than that. The work that would need to be done here would have to include:

• Spending time to actually use the tool to figure out its ins and outs
  • I.e. how do you interact with in a programmatic way
  • This is what takes the bulk of the time and getting this wrong just leads to a poor module or one that's hard to use which is not great
  • Should we have a dep on the pwsh module or just call the exe
  • What options makes sense to expose, what ones should we keep internal
  • Figuring out how this runs through a network logon - Doesn't run under WinRM microsoft/winget-cli#256 would indicate there are potential problems there which needs to be solved
  • How does winget work with a user vs system wide scope, how does that look from a UX/documentation standard
• Writing the tests
  • How do we deal with pre-requisites
  • How do we create self contained tests that aren't reliant on 3rd parties
  • How do we avoid internet requirements and self host packages so the tests don't become flaky and prone to failure
  • Actually writing the tests (this can be time consuming)
• Repeat the same for the _info module to retrieve package information that people will most likely want
• Ongoing maintainance
  • A supported module means ongoing time needed to debug people's problems with the code and fix bugs/add new features

My time is quite limited and while this is on my radar to work on I cannot give any timeframes as to when it might be done.

[mcexit]

Just because these products aren't from Microsoft doesn't make them any less relevant. Each approach the problem of package management on Windows in different ways. Each are valid and fit their own use case with their own advantages and disadvantages.

I understand that these developers have built a community and may have taken different approaches, but Microsoft is actively funding and maintaining their own official open-source package manager now, and a majority of app developers have moved to it. What is the point of using Scoop or Chocolatey at this point aside from getting more niche packages that aren't yet officially packaged in the winget repo? Winget has outpaced them and Scoop or Chocolatey hasn't given the community a reason to not migrate. You can be optimistic, but I give it a year before development stalls on choco & scoop.

We don't maintain any of them. Chocolatey maintain win_chocolatey in their own collection. The win_scoop module is here in this collection but it is maintained by the community whenever someone submits a PR.

Without the community modules, Ansible would have little value to prospective clients compared to alternatives. So you're saying that Red Hat is relying on the community in order to sell paid solutions based on the community's work, but is too cheap to help fund those efforts?

Can't Red Hat dedicated some resources for a developer to spend like one day to create an official winget module?

I spent less than a day and got it working to some extent, and I'm not even a PowerShell or Ansible developer expert. I understand that you'd want to build testing and things around it, and make it "production" ready.

If you ultimately end up doing the work, then know that I appreciate you and your efforts. My frustration isn't with you, it is with Red Hat who still seems to advertise Ansible but doesn't want to adequately fund and assign developers to work on improving it.

[briantist]

I spent less than a day and got it working to some extent, and I'm not even a PowerShell or Ansible developer expert.

This is always how it goes though. The basic POC is quick, and most of the time spent is that last 10-20%.

If you have something working for you, why not use it? As you continue using it you'll likely keep making tweaks and fixes over time, and maybe you'll get it to a point where you're ready to take the step of contributing it or publishing it yourself (as long as you're prepared to do all that production ready stuff, but you won't have to do it alone, there is a community to help).

This has been the story for most of the changes and new modules I've contributed.

[ferventcoder]

@mcexit 👋

Scoop and Chocolatey, while they may still be actively maintained, are not really the way forward in terms of utilizing the tools recommended by Microsoft, and have limited value at this point since winget now has more features.

Winget has outpaced them and Scoop or Chocolatey hasn't given the community a reason to not migrate. You can be optimistic, but I give it a year before development stalls on choco & scoop.

I would implore anyone reading this to determine for yourself if these are factual statements or not.

WinGet still has a ways to go to support what Chocolatey open-source has supported for years. It's also worth stating that Microsoft has a lot of focuses whereas Chocolatey Software has a singular focus - "Make software automation better on Windows."