Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Support for Winget feed
-
Hi,
The winget client v1.0 finally got released! Will proget add that feed type soon?
The reference implementation for the REST API is located here https://github.com/microsoft/winget-cli-restsource
Being a windows shop, we are eagerly awaiting this feature! :)
-
Hey @sylvain-martel_3976 !
Thanks for starting the discussion; I added it to our Other Feed Types to hopefully get some more attention.
I've been following WinGet for a little bit now, and if I'm being totally honest, I don't get it
My understanding of WinGet is that it's basically an index that simply points to installer files. In other words, there are no "WinGet packages" - the client simply goes to the index (a big ole yaml file from what I can gather), and downloads a MSIX installer. Is that what you've seen? Am I off here?
A lot of Chocolatey packages basically do this via a PowerShell script, and that's a big painpoint for folks who try to use it for anything other than some quick/basic workstation steup. Some do bundle their whole installer with Chocolatey, I've seen.
Can you tell me how / why you want to use WinGet? What are you currently doing without WinGet, and how will WinGet make it better?
Thanks,
Dean
-
@dean-houston Hi, well, winget is a bit like apt-get on linux(in fact, winget is based on AppGet codebase which tried to reproduce apt-get on windows). The yaml is a document describing what is required to run the application, pretty much like chocolatey base template requires. Since it's a 1.0 version, we expect alot more functionality to appear in the coming months.
For us, Winget will solve a huge problem that chocolatey has: Meaning, it's not part of Windows and installing the client is actually really difficult to deploy/install with automation tools like ansible(or at least it was last time we checked it, about a year ago.) Management is also a tad cold at giving us the go to use chocolatey since the enterprise version of Choco doesn't have a really big userbase and does become expensive rapidly. Development also move forward slowly.(again, that was a year ago, but we put it aside for those reasons)
But of course, we'll also require the "feed" part for the winget client to work, and we use proget for our feeds internaly.(powershell modules, python libraries, and some RPM)
Our plan is to use Winget to deploy apps on servers using ansible playbook.
-
Found a nice article that describe it better than I can :) (english isn't my primary language)
https://www.infoworld.com/article/3611365/getting-started-with-winget-the-windows-package-manager.html
-
Thanks @sylvain-martel_3976 ! That's really helpful to know.
From a positioning standpoint, I think that WinGet is trying to replace the Windows Store while offering a more developer-friendly experience to create your own apps on Windows. But it's hard to say -- it's only 1.0 as you said, and the positioning has changed a few times already.
Our plan is to use Winget to deploy apps on servers using ansible playbook.
Can you tell us more about this? Lots of questions, hope you don't mind us trying to understand a bit more...
What apps? As in, applications your company created (first-party apps), or third-party ones (like Firefox or SQL Server, etc).
Where to host contents? WinGet doesn't seem to host the installers or package contents, so where will you host these files? Will you keep them on the internet (third-party apps), or have your own custom source (like a CDN or ProGet Asset Directory)
[First-party / custom apps] Do you already make installers for your apps? If not, how will you automate installation?
[First-party / custom apps], Have you explored ProGet's Universal Packages instead? I think these would be better/easier, especially for server applications. We've seen a lot of people use these over Chocolatey.
[Third-party apps] Why use a private feed? Is it for security/vulnerability? Quality checking? Etc.
-
@apxltd said in Support for Winget feed:
Our plan is to use Winget to deploy apps on servers using ansible playbook.
Can you tell us more about this? Lots of questions, hope you don't mind us trying to understand a bit more...
What apps? As in, applications your company created (first-party apps), or third-party ones (like Firefox or SQL Server, etc).
All. First-party and 3rd party. 90% 3rd party though.
We used SCCM to deploy applications on servers, using regular powershell scripts, but we are moving away from that for the server side since we started using terraform/ansible a year ago and are redoing everything using IaC(infrastructure as code) now to code our infra(and help move to the cloud). So we want to deploy those applications with those tools, which also allow for much more control on what is present or not on a srever. Using winget should help to solve some lingering problems too that we have on the windows side, like dependencies of packages that could now be linked directly inside the manifest. Chocolatey could solve the dependencies part too, but as mentioned in the previous post, there were some problemswith choco, mostly non-technicals, that forced us to stop considering it, sadly.
Where to host contents? WinGet doesn't seem to host the installers or package contents, so where will you host these files? Will you keep them on the internet (third-party apps), or have your own custom source (like a CDN or ProGet Asset Directory)
Well, we use a file server to host the packages. We can't use anything hosted on the internet since, for security reasons, the servers do not have internet access. That is one of the main reason we started using proget for python libraries and powershell modules, to be able to deploy them internally with ease and be sure the right versions are deployed/present on the servers.
[First-party / custom apps] Do you already make installers for your apps? If not, how will you automate installation?
Well, most first-party apps are deployed directly from the compilation pipeline. For the rest, the method of deployment depends highly on the form factor of the app(web app, executable, etc). It's often a powershell script when it's not deployed from the pipeline directly.
[First-party / custom apps], Have you explored ProGet's Universal Packages instead? I think these would be better/easier, especially for server applications. We've seen a lot of people use these over Chocolatey.
Proget is fairly new in our environment. I asked for it to be acquired this year because, in our move toward IaC ,we required a powershell repo for powershell DSC modules since servers do not have internet access, so powershellgallery was off-limit. Since then, it's role also expanded a bit to supply some python libraries since AzureDevops only support nuget feeds and a project required python libs. So no, we haven't looked at all at that feature of proget.
[Third-party apps] Why use a private feed? Is it for security/vulnerability? Quality checking? Etc.
Security still stick to their old recommendations of not allowing internet access to public sources, even when they are managed by the suppliers themselves. So we need to have our internal feeds or use old methods like copying manually(which is not even possible anymore for many kind of packages, so the feeds are the way to go for us since we also can supply version numbers for conformity checking when using IaC)
It's also a way to control what modules can be used. I do not agree with that part, since it adds an insane overhead of bringing the packages in-house, but I have no say over that decision :P (No internet access is also the reason we have to use the "classic" installer for proget itself, and that is also a huge pain for updates. I wish we could use the normal process, but can't.)But even if we could access public repos directly, nother reason not to use them as-is, is that scripts from third-part rarely fit our corporate envrironnment. When I tested some choco packages a year ago, we always had to do modifications to the scripts to fit our needs/requirements.
-
Thanks for the detailed explanation @sylvain-martel_3976 - this is quite helpful for me! A few more questions if you don't mind :)
All. First-party and 3rd party. 90% 3rd party though.
Can you give an estimate of the number of Winget "packages" you expect to have in your feed? Like 10? 100? 1000?
What would the process of adding a third-party application to this feed? Will you be recreating the WinGet metadata (package?) from Microsoft's official feed?
Are most of these third-party applications in Microsoft's feed, or are they like from vendors or whatnot?
I'm trying to get a feeling for the concept of "connectors" in WinGet, and if it even makes sense.
Well, we use a file server to host the packages.
Is this just like an ordinary file server, where you use UNC paths? We are have plans to do some major improvements on ProGet's Asset Directory, including enabling replication, cloud storage, and (hopefully) versioning.
So to summarize your usecase...
- WinGet is a means to manage (mostly) third-party applications that you keep on a private file server, and wish to install on other servers through automation
- WinGet is preferred to a regular file server because it includes some metadata like requirements on what to install
- WinGet is preferred to Chocolatey for security and cost reasons
What I'd like to do is build a usecase for how organizations can use WinGet in combination with ProGet (in particular the asset directories) to add value.
-
@apxltd said in Support for Winget feed:
Can you give an estimate of the number of Winget "packages" you expect to have in your feed? Like 10? 100? 1000?
We currently have over 300 SCCM packages for servers. We expect to convert them all in the end.
What would the process of adding a third-party application to this feed? Will you be recreating the WinGet metadata (package?) from Microsoft's official feed?
No idea about this. :-/
Are most of these third-party applications in Microsoft's feed, or are they like from vendors or whatnot?
Well, since winget is pretty new, not many "complex" app are in the Microsoft feed yet(like some dreaded IBM or Oracle applications with their java installer) And because of our internal requirement, we mostly build our install scripts from scratch, using the vendors msi, exe, etc.
Is this just like an ordinary file server, where you use UNC paths? We are have plans to do some major improvements on ProGet's Asset Directory, including enabling replication, cloud storage, and (hopefully) versioning.
Yes, they are simple file servers with shared folders, accessed through UNC.
So to summarize your usecase...
- WinGet is a means to manage (mostly) third-party applications that you keep on a private file server, and wish to install on other servers through automation
- WinGet is preferred to a regular file server because it includes some metadata like requirements on what to install
- WinGet is preferred to Chocolatey for security and cost reasons
Correct on all 3, although I wouldn't say choco is not secure, but mostly, it's client is difficult to deploy and the cost of the enterprise version is prohibitive for us.
What I'd like to do is build a usecase for how organizations can use WinGet in combination with ProGet (in particular the asset directories) to add value.
-
@sylvain-martel_3976 thanks for the additional information; I'm warning up to this idea, but there's a one main area of concern
Are you sure WinGet can help you achieve "Infrastructure as Code"? I'm becoming more and more skeptical of this use case.
The main reason is that there are very few server applications on Microsoft's public WinGet repository. Even their own products like SQL Server aren't there. It's mostly desktop tools like Adobe Reader, Visual Studio, etc. This tells me Microsoft doesn't see WinGet helping with IaC, either.
This is largely the same concern I had with Chocolatey, in particular organizations trying to use Chocolatey for IaC. Their public repository is mostly desktop tools, and using Chocolatey to manage server-based applications is really difficult.
This has really nothing to do with Chocolatey or WinGet, but more that server-based products tend to require infrastructure configuration (user accounts for services, certificates for websites, IP address bindings, firewall changes, database connection strings) -- where as a tool like Adobe Reader simply does not. And infrastructure changes like this are rarely automated as part of the installer.
I definitely get the use case of WinGet (or Chocolatey) as means to distribute desktop applications, and if that were the case - there's a lot more features we need to consider (like proxying Microsoft's public gallery, etc.).... but at the moment I'm just not seeing it for IaC / Server applications.
Perhaps, try doing a proof of concept on your end? I guess you just need to set up a Git Repository, and then, there's your basic WinGet repo?
Ultimately using WinGet in an IaC scenario sounds like a bit more work (and more moving pieces) than just running a PowerShell script to download and run a handful of installers... but I don't know.
I'd love to see what you put together, or more specifics as you learn them yourself.
-
This post is deleted!
