guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] draft addition of github updater


From: Efraim Flashner
Subject: Re: [PATCH] draft addition of github updater
Date: Mon, 16 Nov 2015 16:14:17 +0200

On Sun, 15 Nov 2015 10:32:40 +1000
Ben Woodcroft <address@hidden> wrote:

> Hi,
> 
> 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).
> 
> 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"?

from what I've seen, there are two sets of urls for github, and looking at
the notes in your patch, it looks like you've seen that too. I think your
v1.0 => 1.0 change is ok, it's also part of github's url structure. 

> 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).

Ouch. Will it accept an environmental variable for the access token? Or an
entry in .netrc or in .ssh/config? If I already have an ssh key registered
with github does that change anything? Not directly relevant, but minitube
accepts either having an API key embedded in the compiled version (what
debian does iirc) or querying an environmental variable.

> Thanks,
> ben
> 
> gnu/packages/xml.scm:378:13: pugixml would be upgraded from 1.6 to 1.7
> ...
> gnu/packages/bioinformatics.scm:1610:13: idr would be upgraded from 
> 2.0.0 to 2.0.2

My email client won't let me comment on patches, so I'll add it here:
+  ;; TODO: currently requires the standard "v1.0" or "1.0" style tag names
+  ;; TODO: currently only accepts .tar.gz downloads


+  ;; TODO: should also accept alternative download URLs of style like
+  ;; 
https://github.com/libical/libical/releases/download/v1.0.1/libical-1.0.1.tar.gz

tilda's url is: https://github.com/lanoxx/tilda/archive/tilda-1.2.4.tar.gz
looking at your example and my example, we have:
(string-suffix?
  (string-append "/download/v" (package-version package) "/" (package-name 
package) "-" (package-version package) ".tar.gz"))
(string-suffix?
  (string-append "/archive/" (package-name package) "-" (package-version 
package) ".tar.gz"))

+  (define (github-url? url)
+    (and
+     (string-prefix? "https://github.com/"; url)
+     (or
+      (string-suffix?
+       (string-append "/archive/v" (package-version package) ".tar.gz") url)
+      (string-suffix?
+       (string-append "/archive/" (package-version package) ".tar.gz") url))))

I don't know that archive/${version}.tar.gz is actually anywhere, but a quick 
search of videos.scm shouldn't by itself rule it out.


After my search through videos.scm, I see that github and sourceforge have 
similar url endings.
/${name}-${version}.ending, with the ocassional ${name}_${version}.ending or 
${version}.ending. However, every single package ended in ${version}.ending, no 
matter where it was from.

Have you found the secret of updates?

-- 
Efraim Flashner   <address@hidden>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

Attachment: pgp_vfi54OTM_.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]