unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Eric Bavier <ericbavier@centurylink.net>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH 1/2] import: json: Silence json-fetch output.
Date: Thu, 08 Dec 2016 10:52:37 +0100	[thread overview]
Message-ID: <87r35in3x6.fsf@gnu.org> (raw)
In-Reply-To: <20161207235758.455406ed@centurylink.net> (Eric Bavier's message of "Wed, 7 Dec 2016 23:57:58 -0600")

Eric Bavier <ericbavier@centurylink.net> skribis:

> On Wed, 07 Dec 2016 11:59:10 +0100
> ludo@gnu.org (Ludovic Courtès) wrote:
>
>> Eric Bavier <bavier@member.fsf.org> skribis:
>> 
>> > * guix/import/json.scm (json-fetch): Use http-fetch instead of url-fetch
>> > to avoid writing to stdout and a temporary file for each invocation.
>> > * guix/import/gem.scm (rubygems-fetch): Do not redirect json-fetch
>> > output to /dev/null.
>> > * guix/import/pypi.scm (pypi-fetch): Likewise.  
>> 
>> [...]
>> 
>> >  (define (json-fetch url)
>> >    "Return an alist representation of the JSON resource URL, or #f on failure."
>> > -  (call-with-temporary-output-file
>> > -   (lambda (temp port)
>> > -     (and (url-fetch url temp)
>> > -          (hash-table->alist
>> > -           (call-with-input-file temp json->scm))))))
>> > +  (and=> (false-if-exception (http-fetch url))
>> > +         (lambda (port)
>> > +           (let ((result (hash-table->alist (json->scm port))))
>> > +             (close-port port)
>> > +             result))))  
>> 
>> It’d be better to not catch exceptions raised by ‘http-fetch’ here.
>> Instead they’d be caught at the top level and a detailed error message
>> would be displayed, which is always better than silently ignoring
>> issues.
>> 
>> However we’d need to check if there are uses where this is a problem.
>> For example, there might be updaters or importers that assume that #f
>> means that the package doesn’t exist or something like that.
>> 
>> WDYT?
>
> The importers that use json-fetch all do something like '(and=> meta
> ->package)', so a #f result from json-fetch is passed up to (@ (guix

OK.

So if we instead “let the exception through”, ‘guix import’ would
something like “failed to download from http://…: 404 (Not Found)”,
which is worse than “package not found in repo” in this case.

A middle ground would be this:

  (guard (c ((http-get-error? c)
             (if (= 404 (http-get-error-code c))
                 #f ;this is “expected”, just means the package isn’t known
                 (raise c)))) ;using (srfi srfi-34) here
    (let* ((port (json->scm port)))
      …))

That way, 404 would still be treated as an expected error meaning
“package does not exist in upstream repo”, but more problematic errors
(DNS lookup errors, 403, etc.) would go through.

How does that sound?

Thanks,
Ludo’.

  reply	other threads:[~2016-12-08  9:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-05  5:03 [PATCH 1/2] import: json: Silence json-fetch output Eric Bavier
2016-12-05  5:03 ` [PATCH 2/2] import: cpan: Add CPAN updater Eric Bavier
2016-12-07 11:02   ` Ludovic Courtès
2016-12-08  5:45     ` Eric Bavier
2016-12-07 10:59 ` [PATCH 1/2] import: json: Silence json-fetch output Ludovic Courtès
2016-12-08  5:57   ` Eric Bavier
2016-12-08  9:52     ` Ludovic Courtès [this message]
2016-12-14 15:16       ` David Craven
2016-12-15 17:37         ` Ludovic Courtès
2016-12-20  2:50           ` Eric Bavier

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=87r35in3x6.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=ericbavier@centurylink.net \
    --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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).