all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
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: Tue, 23 Feb 2016 14:22:21 +0100	[thread overview]
Message-ID: <87vb5fk1de.fsf@gnu.org> (raw)
In-Reply-To: <56C92B77.3050601@uq.edu.au> (Ben Woodcroft's message of "Sun, 21 Feb 2016 13:13:59 +1000")

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

> Unfortunately I found a further bug - the updated URL for the new
> package was actually the old URL not the updated one, and fixing this
> required some refactoring.

OK.

> I'm afraid I'm almost out of time for this until the end of March, so
> if there are any further substantive changes we might have to let this
> slip the upcoming release, unless someone else can continue this
> work. Soz..

No problem.  It’s OK to leave improvements for later.  We can always add
this version now as long as it’s functional and doesn’t break anything.

> One way in which this could be improved in the future would be to
> accept odd source GitHub URLs and return the newest version, but error
> out when the URL needs to be guessed. That way, at least all
> GitHub-sourced packages can be checked for updates even if they cannot
> all be updated in place. I don't think this would be especially hard
> to implement and would be quite reliable.

OK.

> On 04/01/16 06:46, Ludovic Courtès wrote:
>> Ben Woodcroft<b.woodcroft@uq.edu.au>  skribis:
>>
>>> It seems I miscounted before, but now it is 129 of 146 github
>>> "release" packages recognised with 28 suggesting an update - see the
>>> end of email for details. There is one false positive:
>>>
>>> gnu/packages/ocaml.scm:202:13: camlp4 would be upgraded from 4.02+6 to
>>> 4.02.0+1
>>>
>>> This happens because the newer versions were not made as official
>>> releases just tags, so the newer versions are omitted from the API
>>> response, plus there's the odd version numbering scheme. Guix is up to
>>> date.
>> I guess we could filter out such downgrades by adding a call to
>> ‘version>?’, no?
>
> My impression is that code elsewhere (yours?) already does this, but
> version>? does not work as intended for this corner case.

Indeed:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (version>? "4.02+6" "4.02.0+1")
$2 = #f
--8<---------------cut here---------------end--------------->8---

I would argue that upstream chose a confusing numbering scheme is
4.02.0+1 is supposed to be older…

>> Rather use (guix http-client) and something like:
>>
>>    (let ((port (http-fetch url)))
>>      (dynamic-wind
>>        (const #t)
>>        (lambda ()
>>          (json->scm port))
>>        (lambda ()
>>          (close-port port))))
>>
>> This avoids the temporary file creation etc.
>
> This sounds preferable but did not work as I kept getting 403
> forbidden. Displaying the URI for instance with (string-append uri
> "\n") gives the below. I understand the error is trivial, but just
> wanted to communicate the URI object.
>
> ERROR: In procedure string-append:
> ERROR: In procedure string-append: Wrong type (expecting string):
> #<<uri> scheme: https userinfo: #f host: "api.github.com" port: #f
> path: "/repos/torognes/vsearch/releases" query:
> "access_token=27907952ef87f3691d592b9dcd93cd4b6f20625f" fragment: #f>

That’s because this is a URI object, not a string.

>>> +;; TODO: is there some code from elsewhere in guix that can be used instead of
>>> +;; redefining?
>>> +(define (find-extension url)
>>> +  "Return the extension of the archive e.g. '.tar.gz' given a URL, or
>>> +false if none is recognized"
>>> +  (find (lambda x (string-suffix? (first x) url))
>>> +        (list ".tar.gz" ".tar.bz2" ".tar.xz" ".zip" ".tar")))
>> Remove this procedure and use (file-extension url) instead, from (guix utils).
>
> I figured there was something out there. The problem is file-extension
> returns, for example, "gz" when we are after "tar.gz".

Oh, I see.

> From 29dc5a809e6d8796279911a993ef1b2237c810ca Mon Sep 17 00:00:00 2001
> From: Ben Woodcroft <donttrustben@gmail.com>
> Date: Sun, 15 Nov 2015 10:18:05 +1000
> Subject: [PATCH] import: Add github-updater.
>
> * guix/import/github.scm: New file.
> * guix/scripts/refresh.scm (%updaters): Add %GITHUB-UPDATER.
> * doc/guix.texi (Invoking guix refresh): Mention it.

Make sure to add github.scm in Makefile.am.  Otherwise LGTM!

Once this is in, I’ll see if I can make that ‘http-fetch’ change I was
suggesting.

Thank you!

Ludo’.

  parent reply	other threads:[~2016-02-23 13:22 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 [this message]
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

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=87vb5fk1de.fsf@gnu.org \
    --to=ludo@gnu.org \
    --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.