GNU bug report logs - #24450
pypi importer outputs strange character series in optional dependency case.

Previous Next

Full log

Message #103 received at 24450 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 24450 <at> debbugs.gnu.org
Subject: Re: [PATCHv2] Re: pypi importer outputs strange character series in
 optional dependency case.
Date: Mon, 10 Jun 2019 22:13:38 +0200

Hi Maxim,

thanks for your patience in addressing my comments.  I appreciate it!

>> I think the double application of file-sans-extension and the
>> intermediate variable name “root-directory” for something that is a file
>> is a little confusing, but I don’t have a better proposal (other than to
>> replace file-extension and file-sans-extension with a match expression).
>
> Done, w.r.t. using "match":
>
> --8<---------------cut here---------------start------------->8---
> @@ -198,10 +198,12 @@ be extracted in a temporary directory."
>      ;; that will be created upon decompressing it. If the filetype is not
>      ;; supported, return #f.
>      (if (compressed-file? url)
> -        (let ((root-directory (file-sans-extension (basename url))))
> -          (if (string=? "tar" (file-extension root-directory))
> -              (file-sans-extension root-directory)
> -              root-directory))
> +        (match (file-sans-extension (basename url))
> +          (root-directory
> +           (match (file-extension root-directory)
> +             ("tar"
> +              (file-sans-extension root-directory))
> +             (_ root-directory))))
>          (begin
>            (warning (G_ "Unsupported archive format (~a): \
>  cannot determine package dependencies") (file-extension url))
> --8<---------------cut here---------------end--------------->8---

The first application of “match” matches anything.  What I had in mind
was really a slightly different approach, namely to split up the “url”
string at dots and then match the resulting list of strings.

Something like this:

  (match (string-split "hello.tar.gz" #\.)
   ((base "tar" (or "bz2" "gz")) base)
   ((base ext) base))

> I don't see much of a problem with the current design since there are
> two questions being answered:
>
> 1) What should be the directory name of the extracted package (retrieved
>    from the base name of the archive).
> 2) What extractor should be used (zip vs tar).
>
> These two questions are orthogonal, and that the same primitive get used
> to answer both is an implementation, or rather, an optimization detail.
>
>> I wonder if we could do better and answer the question just once.
>
> The questions are different :-). We could optimize, but that would be at
> the price of expressiveness (squash the two questions into one solving
> space).

Okay.  I guess I’m too picky :)
I’d be happy if we could move the checks to tiny named procedures, but
it’s probably fine the way it is.

Thanks!

--
Ricardo

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.