Easier private sources
denelon opened this issue · 6 comments
Discussed in microsoft/winget-cli#2168
Originally posted by aqua-nerd May 19, 2022
Thought I would have a play with winget this week thinking maybe its come of age. Thought by now private sources would be an easy thing to do. It seems pretty convoluted to get a private source going since its basically just somewhere to host manifest files it should be able to work with any basic web server. I don't see the point in having to spin things up in Azure like Cosmos DB and other things I know nothing about just to host a few packages. Some of us are still on-prem shops and like most other Microsoft projects your leaving these shops behind! Then you have this guy trying to shill his winget.pro service all over the place, its super frustrating. Please make a reference winget rest source that we can run on-prem.
Ok rant over, I'm off to deploy a few packages via GPO like its 2008!
@daperoni I think it would be a good idea to put into a container and have it interact with mongo DB for the Manifest. I know that AZfunctions can run off a container, I have been trying to put the functions into one but I am having dependencies issues with utils. I am on a case where we want to run winget repo locally due to internal infra and having to use Azure is a no go.
if you could provide some feedback on this It would be amazing.
It should be possible to host a simple repository in a file system, object store, or git repository. This is the way of modern package registries.
I agree with the need for simplicity. I've hosted private repositories and mirrors for all sorts of package managers over the years, and not one of them has required me to run a webapp in Azure or host a database server. They've all been simple file and folder structures that can be served in any number of ways and easily kept up to date with tools like rsync.
I can understand the REST API for hosting Microsoft's central server that might have tens/hundreds of thousands of packages being served to millions of users one day. Keeping the main catalog up to date and consistent globally, and rebuilding the indexes after every change would be a nightmare. Plus every PC would have to download and reprocess the entire catalogue every time it changed.
However, if I'm a business that just wants to self-host a small collection of in-house packages, I want something that's as simple, flexible, and easy to setup as possible. A static web server, S3 bucket, or SMB share is really tough to beat.
Adding my thoughts to the rant: Since this is reference implementation (at least it claims to be) it should be as simple as possible to satisfy the interface. Therefore no need for any "real" storage backend at all, just putting the packages in the projectdir should be enough. Connecting it with a "real" backend like s3, mongo or fancy azure stuff is the task of vendors providing a production ready solution like microsoft or winget.pro do.
I just wanted to evaluate if winget is something I want to use to distribute my own applications, so I though I can just write my own little rest server to see how everything works, however the included openapi files seem to be wrong or incomplete, the included winget resource does not respond to any route specify in the openapi files with anything other than "resource not found" or "blob not found", the included msstore source at least respons with some json, but also doesn't give me anything useful. Trying to add my own source shows that winget source add https://localhost:7071 shows that it requests https://localhost:7071/source.msix which is nowhere mentioned in the documentation, so no idea how to respond to the request.
This situations leaves me in question if either I am to stupid to follow the specification, or if microsoft is to stupid to properbly document its api, or if they just don't want anyone to implement their own repository
@danielr1996 if you tack on "-t Microsoft.REST" when adding the local source you should see a different result. The "default" is the PreIndexed package.
I just checked and we need to add that to https://learn.microsoft.com/windows/package-manager/winget/source