From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH] import: pypi: read requirements from wheels. Date: Tue, 26 Jan 2016 11:11:53 +0100 Message-ID: <87fuxkvedy.fsf@gnu.org> References: <1453414080-23296-1-git-send-email-tipecaml@gmail.com> <87twm2n3je.fsf@gnu.org> <56A53365.5090404@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aO0bP-0003FT-7a for guix-devel@gnu.org; Tue, 26 Jan 2016 05:12:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aO0bL-0000q6-V1 for guix-devel@gnu.org; Tue, 26 Jan 2016 05:11:59 -0500 In-Reply-To: <56A53365.5090404@gmail.com> (Cyril Roelandt's message of "Sun, 24 Jan 2016 21:26:13 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Cyril Roelandt Cc: guix-devel@gnu.org Cyril Roelandt skribis: > On 01/24/2016 09:08 PM, Ludovic Court=C3=A8s wrote: >> Cyril Roelandt skribis: >>=20 >>> * guix/import/pypi.scm (latest-wheel-release): New function. >>=20 >> s/function/procedure/ :-) >>=20 >> Please also mention the changes in =E2=80=98guess-requirements=E2=80=99, >> =E2=80=98compute-inputs=E2=80=99, etc. >>=20 >> So do I get it right that pypi now provides packages both in Wheels and >> in =E2=80=9Ctraditional=E2=80=9D format, but that Wheels provides more i= nfo about >> dependencies? >>=20 >> 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. OK, got it, that=E2=80=99s nice. Could you add a comment at a relevant pla= ce in the code to explain that? >>> + (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_requir= es")) >>> + (requirements (hash-ref (list-ref run_requir= es 0) >>> + "requires"))) >>> + (map (lambda (r) >>> + (python->package-name (clean-requirement r= ))) >>> + requirements))))) >>> + (lambda () >>> + (delete-file json-file) >>> + (rmdir dirname)))))) >>=20 >> Eventually I wonder if we should do this in a derivation instead of >> hoping for =E2=80=98unzip=E2=80=99 & co. to be available there (=E2=80= =9Ceventually=E2=80=9D, because >> the problem is already present with the =E2=80=98requirements.txt=E2=80= =99 thingie.) >>=20 > > I think it is fine as is, seeing how it makes Python packaging much > easier :) I mean the functionality itself is perfect, but what I mean is that the above process (taking an archive + unzip + guile-json as input, producing a list of requirements as an output) could be modeled as a derivation. Anyway, no rush for that. Thanks, Ludo=E2=80=99.