Expose Links as an API Property

[thecliguy]

The results returned by the repology website includes "Links(s)" when querying a project like so: https://repology.org/project/<NAME>/packages

Would it be possible to expose "Links(s)" as a property of the results returned when querying via the API?

Also, what is the significance of the "(s)" in "Links(s)"? Is is just a typo? Is it supposed to say "Link(s)"?

[AMDmi3]

Would it be possible to expose "Links(s)" as a property of the results returned when querying via the API?

What's your usecase? It's possiblt, but it'll require specific API, as including the links with existing API would be too heavy.

Also, what is the significance of the "(s)" in "Links(s)"? Is is just a typo? Is it supposed to say "Link(s)"?

Fixed, thank you!

[thecliguy]

What's your usecase? It's possiblt, but it'll require specific API, as including the links with existing API would be too heavy.

I was particularly interested in returning the "Upstream homepage" link as a means of deriving whether a package is aligned with an original repo or a fork.

[AMDmi3]

This is often not reliable, as homepage link usually remains the same when package switches to the fork. Download links would be more reliable but not many repositories provide them. Do you need this for one time or you need continuous availability of data? Do you need this for specific repo?

This looks too specific for a dedicated API, but it's possible to revive https://github.com/repology/repology-exports and set up daily export.

[thecliguy]

This is often not reliable, as homepage link usually remains the same when package switches to the fork. Download links would be more reliable but not many repositories provide them.

Ahh, OK, that makes sense to use the Upstream Download link (when avaiable) as a more reliable source of data. Thank you for that tip.

Do you need this for one time or you need continuous availability of data? Do you need this for specific repo?

Occasionally I will check the state of packages for ssh-audit. I'm not a maintainer of the project, just an occasional contributor.

This is just a thought (and perhaps a naive one)... You mentioned that exposing links would make the API too heavy... What if when calling the API it was to accept an optional boolean showlinks=1 so that links are only returned if explicitly requested? Another thought... Could the links data that's served be cached on the backend to reduce DB load?

[darkdragon-001]

I would be interested in Package Page links to display nice links for users with an easy way to install. As an alternative I could probably generate "Install links" directly. Which property is the name used to install a package? Is it visiblename? E.g. apt-get install PACKAGE.

[AMDmi3]

@thecliguy unfortunately no, the very possibility to request links would allow excess load on the server. And no, links cannot be cached - it's the heaviest table in repology database, and different packages are requested each time, so it'd be a waste of memory.

[AMDmi3]

@darkdragon-001 no, it is binname, sometimes srcname

[kzndotsh]

+1

[AMDmi3]

@kzndotsh what's your use case?

[kzndotsh]

@kzndotsh what's your use case?

I run a discord community (https://discord.gg/linux) and we maintain a bot for our server https://github.com/allthingslinux/tux

Our goal is to add a lot of various utility features relating to linux so I started working on a Repology integration/wrapper. At first from scratch, then came across https://repology-client.sysrq.in/index.html.

I found it strange that no URL was provided but I could find the URLs on the package web pages themselves so I considered it as the library just being undeveloped.

Looking further, I saw in your source code that you do have in fact links available but no API spec showed them in use so I came to find this issue now :)

[AMDmi3]

OK, but what's the specific use case for links?

[kzndotsh]

OK, but what's the specific use case for links?

Sorry, sorta left that out specifically lol. Basically to provide links on the embeds generated from either individual package queries or package search lists.

e.g.

• user runs /repology info [package] <repo> or /repology search [package]
• we respond back with a neat and pretty summary embed consisting of most of the data you all currently provide so the addition of a link just makes it easier user experience wise to quickly navigate to the source repo if they so desire.

[AMDmi3]

Hmm, that makes sense. I guess with migration to rust we have some additional performance budget so we can expose more info through additional endpoint. Do you expect the same format (e.g. per-package info) or some kind of aggregated format?

[kzndotsh]

Hmm, that makes sense. I guess with migration to rust we have some additional performance budget so we can expose more info through additional endpoint. Do you expect the same format (e.g. per-package info) or some kind of aggregated format?

To be fair, anything is better than nothing.

I'm not entirely sure what you imagine for an aggregated format though. Explain further?

Also I am curious - what of these URL/URL categories are generated dynamically vs not e.g. them being "manually curated/added"? https://repology.org/project/bash/information

[AMDmi3]

I'm not entirely sure what you imagine for an aggregated format though. Explain further?

Something akin to what is shown on package 'information' tab, e.g. all known links without their relation to specific packages.

Also I am curious - what of these URL/URL categories are generated dynamically vs not e.g. them being "manually curated/added"?

Links related to upstream are obviously manual, links related to repositories are generated (on Repology or in a few cases on repository side).