Re: [PATCH] draft addition of github updater

[ludo@gnu.org (Ludovic Courtès)]

Hi!

Ben Woodcroft <b.woodcroft@uq.edu.au> skribis:

> Importing from GitHub seems very non-trivial, but can we update?
> There's a number of issues with the attached patch but so far out of
> the 171 github package in guix, it recognizes 101, and 17 are detected
> as out of date (see below).

Woow, nice!

> I have two questions:
>
> 1. Some guess-work is required to get between the version as it is
> defined in guix, and that presented in the github json, where only the
> "tag_name" is available. Is it OK to be a little speculative in this
> conversion e.g. "v1.0" => "1.0"?

I guess so.  What I would do is do that conversion when the tag matches
“^v[0-9]” and leave the tag as-is in other cases.  WDYT?

We can always add more heuristics later if we find that there’s another
widely-used convention for tag names.

> 2. For mass-updates, it fails when it hits the abuse limit on github
> (60 api requests per hour). This can be overcome by authenticating
> with an access token, but I don't think that token should go in the
> git repository. So I'm after some guidance on the best way of the user
> providing a token to the updater (or some other workaround).

Argh, that’s annoying.  How does it fail exactly?  What’s the impact on
the behavior of ‘guix refresh’?

I guess (guix import github) could contain something like:

  (define %github-token
    ;; Token to be passed to Github.com to avoid the 60-request per hour
    ;; limit, or #f.
    (make-parameter (getenv "GUIX_GITHUB_TOKEN")))

and we’d need to document that, or maybe write a message hinting at it
when we know the limit has been reached.

WDYT?

> +;; TODO: Are all of these imports used?
> +(define-module (guix import github)
> +  #:use-module (ice-9 binary-ports)

By default modules are compiled with -Wunbound-variables, so you can
find out by removing modules until you get an “unbound variable”
warning.

> +(define (json-fetch* url)
> +  "Return a list/hash representation of the JSON resource URL, or #f on
> +failure."
> +  ;; TODO: make silent
> +  (call-with-temporary-output-file
> +   (lambda (temp port)
> +     (and (url-fetch url temp)
> +          (call-with-input-file temp json->scm)))))

See how ‘pypi-fetch’ makes it silent.

Overall it LGTM.

I was thinking we could have a generic Git updater that would look for
available tags upstream.  I wonder how efficient that would be compared
to using the GitHub-specific API, and if there would be other
differences.  What are your thoughts on this?

Thanks!

Ludo’.