all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Efraim Flashner <efraim@flashner.co.il>
To: Ben Woodcroft <b.woodcroft@uq.edu.au>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Re: [PATCH] draft addition of github updater
Date: Mon, 16 Nov 2015 16:14:17 +0200	[thread overview]
Message-ID: <20151116161417.0750dd56@debian-netbook> (raw)
In-Reply-To: <5647D2A8.8040603@uq.edu.au>

[-- Attachment #1: Type: text/plain, Size: 3505 bytes --]

On Sun, 15 Nov 2015 10:32:40 +1000
Ben Woodcroft <b.woodcroft@uq.edu.au> 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   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

      parent reply	other threads:[~2015-11-16 14:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-15  0:32 [PATCH] draft addition of github updater Ben Woodcroft
2015-11-16  9:15 ` Ludovic Courtès
2015-12-20  0:42   ` Ben Woodcroft
2016-01-03 20:46     ` Ludovic Courtès
2016-01-05 16:05       ` Ricardo Wurmus
2016-04-15  8:42         ` Updaters now receive package objects Ludovic Courtès
2016-02-21  3:13       ` [PATCH] draft addition of github updater Ben Woodcroft
2016-02-21  3:17         ` Ben Woodcroft
2016-02-23 13:22         ` Ludovic Courtès
2016-02-27  3:14           ` Ben Woodcroft
2016-02-27 11:55             ` Ricardo Wurmus
2016-02-28 14:35               ` Ludovic Courtès
2015-11-16 14:14 ` Efraim Flashner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151116161417.0750dd56@debian-netbook \
    --to=efraim@flashner.co.il \
    --cc=b.woodcroft@uq.edu.au \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.