From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH] draft addition of github updater Date: Mon, 16 Nov 2015 10:15:35 +0100 Message-ID: <87h9kmb8zs.fsf@gnu.org> References: <5647D2A8.8040603@uq.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39020) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyFsz-0006sy-M5 for guix-devel@gnu.org; Mon, 16 Nov 2015 04:15:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZyFsv-0001M2-Ke for guix-devel@gnu.org; Mon, 16 Nov 2015 04:15:41 -0500 In-Reply-To: <5647D2A8.8040603@uq.edu.au> (Ben Woodcroft's message of "Sun, 15 Nov 2015 10:32:40 +1000") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ben Woodcroft Cc: "guix-devel@gnu.org" Hi! Ben Woodcroft 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" =3D> "1.0"? I guess so. What I would do is do that conversion when the tag matches =E2=80=9C^v[0-9]=E2=80=9D and leave the tag as-is in other cases. WDYT? We can always add more heuristics later if we find that there=E2=80=99s ano= ther 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=E2=80=99s annoying. How does it fail exactly? What=E2=80=99s t= he impact on the behavior of =E2=80=98guix refresh=E2=80=99? 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=E2=80=99d 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 =E2=80=9Cunbound variable=E2= =80=9D 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 =E2=80=98pypi-fetch=E2=80=99 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=E2=80=99.