all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Cyril Roelandt <tipecaml@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH] import: pypi: read requirements from wheels.
Date: Sun, 24 Jan 2016 21:26:13 +0100	[thread overview]
Message-ID: <56A53365.5090404@gmail.com> (raw)
In-Reply-To: <87twm2n3je.fsf@gnu.org>

On 01/24/2016 09:08 PM, Ludovic Courtès wrote:
> Cyril Roelandt <tipecaml@gmail.com> skribis:
> 
>> * guix/import/pypi.scm (latest-wheel-release): New function.
> 
> s/function/procedure/  :-)
> 
> Please also mention the changes in ‘guess-requirements’,
> ‘compute-inputs’, etc.
> 
> So do I get it right that pypi now provides packages both in Wheels and
> in “traditional” format, but that Wheels provides more info about
> dependencies?
> 
> IOW: What does this buy us?  :-)

When uploading a package to PyPI, one may provide a wheel in addition to
a tarball. The wheel is built by setuptools, and contains metadata,
which includes *all* the requirements specified by the authors.

It is much better than reading "requirements.txt", because this file is
not mandatory.

Since wheels may not be provided, we need to keep the old way of
retrieving dependencies, even though it is not extremely reliable.

> 
>> +(define (latest-wheel-release pypi-package)
>> +  "Return the url of the wheel for the latest release of pypi-package, of #f if
> 
> Line a bit long.  s/of/or/
> 
>> +  (define (read-wheel-metadata wheel-archive)
>> +    ;; Given WHEEL-ARCHIVE, a ZIP Python wheel archive, return the package's
>> +    ;; requirements.
>> +    (let* ((dirname (string-append
>> +                     (string-join
>> +                      (list-head
>> +                       (string-split (last (string-split wheel-url #\/))  #\-) 2)
>> +                        "-")
> 
> "-" should be aligned with (list-head.
> 
> I would be best to turn this transformation into a top-level procedure,
> say ‘wheel-url->extracted-directory’.
> 
>> +                     ".dist-info"))
>> +           (json-file (string-append dirname "/metadata.json")))
>> +      (and (system* "unzip" "-q" wheel-archive json-file)
>> +           (dynamic-wind
>> +             (const #t)
>> +             (lambda ()
>> +               (call-with-input-file json-file
>> +                 (lambda (port)
>> +                   (let* ((metadata (json->scm port))
>> +                          (run_requires (hash-ref metadata "run_requires"))
>> +                          (requirements (hash-ref (list-ref run_requires 0)
>> +                                                  "requires")))
>> +                     (map (lambda (r)
>> +                            (python->package-name (clean-requirement r)))
>> +                          requirements)))))
>> +             (lambda ()
>> +               (delete-file json-file)
>> +               (rmdir dirname))))))
> 
> Eventually I wonder if we should do this in a derivation instead of
> hoping for ‘unzip’ & co. to be available there (“eventually”, because
> the problem is already present with the ‘requirements.txt’ thingie.)
> 

I think it is fine as is, seeing how it makes Python packaging much
easier :)

> Could you add a test in tests/pypi.scm?
> 

Will do!

Cyril.

  reply	other threads:[~2016-01-24 20:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-21 22:08 [PATCH] import: pypi: read requirements from wheels Cyril Roelandt
2016-01-24 20:08 ` Ludovic Courtès
2016-01-24 20:26   ` Cyril Roelandt [this message]
2016-01-26 10:11     ` Ludovic Courtès
2016-02-27  2:49   ` Cyril Roelandt
2016-03-02  9:54     ` Ludovic Courtès
2016-03-25 23:24       ` Cyril Roelandt
2016-03-26  1:45       ` Cyril Roelandt
2016-05-06 20:27         ` Leo Famulari
2016-05-15 19:49           ` Ludovic Courtès
2016-06-14 20:14             ` Cyril Roelandt

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=56A53365.5090404@gmail.com \
    --to=tipecaml@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=ludo@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.