Hi!
Ben Woodcroft <b.woodcr...@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’.
