WinGet Integration about repology-updater HOT 11 OPEN

I'd also like to understand if there is a way to better handle how package information is pulled from WinGet, as several winget packages are listed as outdated, when the philosophy over at the winget-pkgs repo is to keep all the versions possible as legacy versions, since with Windows packages there is a larger chance that an organization may need a specific version of any given package,

from repology-updater.

One of our community members has started digging into the Repology tooling. Before we add a tool to help us with mappings between WinGet package identifiers and repology "projects" and "packages" I wanted to reach out to see if there is a better way we should reason about this kind of mapping.

There is https://repology.org/tools/project-by which does exactly that - maps package names to repology projects.

microsoft/winget-pkgs#146673

You could've asked to add vulnerable flag to the API. Webpage scraping is not tolerated, also the client must set distinctive user-agent and maintain rate limit or 1RPS (see API TOS). If it would do a lot of requests it may be better to set up a bulk export instead.

I'd also like to better understand the logical distinction made here between projects and packages.

Project roughly corresponds to upstream project (Firefox). Package is a single package of it in some repository (Mozilla Firefox 124.0.1 in winget).

I saw a #658 (comment) about avoiding "windows-only" projects.

Repology is targeted at F/OSS and cross-platform software ecosystem. Projects present in windows and macos repositories only are hidden from the search, though otherwise tracked.

from repology-updater.

I'd also like to understand if there is a way to better handle how package information is pulled from WinGet, as several winget packages are listed as outdated, when the philosophy over at the winget-pkgs repo is to keep all the versions possible as legacy versions

There should be no problem with legacy versions - as long as a newer version is available, older versions would be marked as legacy instead of outdated. There are some exceptions to this logic though, it would make sense to look at specific examples.

from repology-updater.

microsoft/winget-pkgs#146673

You could've asked to add vulnerable flag to the API. Webpage scraping is not tolerated, also the client must set distinctive user-agent and maintain rate limit or 1RPS (see API TOS). If it would do a lot of requests it may be better to set up a bulk export instead.

I've closed the PR; Where should I make the request to add to the API?

from repology-updater.

I've closed the PR; Where should I make the request to add to the API?

It's still not clear to me whether you need an API change adding vulnerable flag (but it makes sense to add it regardless) or a bulk export. How many requests would a tool generate and in which periods?

from repology-updater.

I've closed the PR; Where should I make the request to add to the API?

It's still not clear to me whether you need an API change adding vulnerable flag (but it makes sense to add it regardless) or a bulk export. How many requests would a tool generate and in which periods?

My thoughts are that the tool would request the specific projects that are listed as vulnerable at winget, along with the specific versions that are vulnerable.

Looking at the documentation, this could probably be a single call to the Filtered Packages endpoint with the query string ?inrepo=winget&vulnerable=1, so long as the Package dictionary also had an indication of whether or not each was vulnerable (perhaps a list of the CVEs?)

One to two calls daily or potentially even less frequently would likely be enough for some basic tooling to be built on Winget's side

from repology-updater.

Well yes, this looks like it could be done with a single API request. It's rather heavy as it returns a lot of packages, but I guess it's ok if it's not too frequent. I've added vulnerable flag to API projects output. You can use srcname to map repology data back winget packages. What's left is that not all packages are returned by the API because of being windows only, I might reconsider that.

from repology-updater.