GNU bug report logs - #53818
[PATCH 0/3] Add Repology updater

Previous Next

Full log

View this message in rfc822 format

From: Maxime Devos <maximedevos <at> telenet.be>
To: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>, Ludovic Courtès <ludo <at> gnu.org>
Cc: 53818 <at> debbugs.gnu.org, Xinglu Chen <public <at> yoctocell.xyz>
Subject: [bug#53818] [PATCH 0/3] Add Repology updater
Date: Mon, 14 Feb 2022 17:07:07 +0100

[Message part 1 (text/plain, inline)]

Nicolas Goaziou schreef op ma 14-02-2022 om 11:40 [+0100]:
> [...]. Assuming I could manage this,
> fetching all version information would take considerable time, and,
> since many packages are from GitHub, the party would stop early anyway
> with GitHub refusing to proceed and requesting some token I don't have.
> 
> OTOH, using Repology API, I get the information I want in about ten
> seconds. Sure, I need to eyeball through the results, filtering false
> positives (around 4% in my case), but it still is a practical solution.
> 
> IMO, to be useful, updaters may need to rely on an external service,
> which may, or may not, belong to the Guix ecosystem. They also need
> a good UI.

To avoid exceeding API limits and reduce network traffic, I suggest the
following change:

  Cache HTTP responses, using http-fetch/cached instead of
  http-fetch.  When something is in the cache and not expired,
  this avoids some network traffic and does not bring us closer
  to the API limits.

  When it is expired (and in the cache), then at least
  http-fetch/cached makes a conditional request with
  If-Modified-Since, which GitHub does not count against the rate
  limit, assuming a ‘304 Not Modified’ response!

That does not address all your concerns but it should help I think.

Greetings,
Maxime.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.