Repository REST API

[denelon]

I'd like to be able to have a repository accessible via REST APIs rather than a signed MSIX package.

The API will need a full design. This will also have an impact on client behavior. The MSIX index package can become a backup mechanism if the APIs are offline, or the client is unable to connect.

Notes:
The client needs to be able to get the list of packages to enable "search"
The client needs to be able to get the manifest so it can "install"
This implies that the client will build a local cache of packages after retrieving the list so they can perform a local search.
In the future we may create a web based search API (TBD).
The contents of the Microsoft Community Package manager should be available via this API once it's built.

[svmastersamurai]

This aspect is super interesting to those of us in orgs that build and deploy internally built software.

As someone who has to manage chocolatey infrastructure: please please please keep this design simple.

As an operator I would love to be able to run a tool over "packages" to generate a static website. Assuming the API is of trivial complexity, the server might be about 20 or 30 lines of code in Go or I could use something like apache or nginx to serve the content. I could more easily leverage a CI/CD system to handle rebuilding the repo metadata when there is a change.

For example we looked into sleet but chocolatey speaks an older dialect of nuget and that ended up being non-viable.

I think other package managers like RPM and apt are great examples to draw inspiration from.

The tools for repo management should ideally be cross-platform so we could build or manage changes to repo metadata on either POSIX-based OSes or Windows.

[denelon]

@svmastersamurai That's great feedback. I like the idea of running the tool over the packages. Would you think in terms of UNC style path's to the binaries or would HTTP still be OK?

I'm thinking about a concept where you might have the installers in a structure that looks like the manifests directory in the repository here, and then having the manifests able to co-locate in the same structure. If the installers are MSIX, we can pull nearly all of the meta-data to generate the manifest based on what is found.

[svmastersamurai]

@denelon I think to generate a static website that makes perfect sense. This assumes that there will be adequate saturation of MSIX usage of course! There are a lot of legacy installers out there, so would this be able to also handle the usual suspects we know about?

Our team manages multiple operating systems so we tend to prefer HTTP since it is usable cross platform. We use the same webservers to serve installers for Windows that we do for Munki packages on MacOS and RPMs for our fedora fleet.

One thing we do for redundancy is have a few locations to retrieve the installers from. It appears the package spec supports this, so from a tooling perspective if I have 5 mirrors with different hostnames it would be nice to be able to have the tool aware of the mirrors (in a simplistic sense, I can just give it a list in a file for example) and be able to append those sources to the specs if they don't exist. From the winget-cli's perspective it could cycle through the mirrors until it finds one that is accessible. This would probably lead to templating within the package spec, which I admittedly haven't dived too much into this project to know if that's supported or if there was a plan for that already 😄.

[majkinetor]

As an operator I would love to be able to run a tool over "packages" to generate a static website.

This deserves a separate ticket IMO and has nothing to do with REST interface to repository. Such tool would indeed be great for multiple reasons, one of which is that it allows anybody to keep their public list of packages and host it anywhere (i.e. github pages and friends).

Such tool might not be practical in producing all desired functionality of REST backend such as versioning and dependencies although it could go long way into that direction.