From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:52110) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hbUAn-0006xY-E9 for guix-patches@gnu.org; Thu, 13 Jun 2019 14:10:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hbUAl-0000JT-Uv for guix-patches@gnu.org; Thu, 13 Jun 2019 14:10:05 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:50763) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hbUAl-0000IF-Np for guix-patches@gnu.org; Thu, 13 Jun 2019 14:10:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hbUAk-0003Ai-PK for guix-patches@gnu.org; Thu, 13 Jun 2019 14:10:02 -0400 Subject: [bug#36048] [PATCH] guix: import: hackage: handle hackage revisions Resent-Message-ID: From: Timothy Sample References: <20190601223636.74362-1-rob@vllmrt.net> <87sgse43sc.fsf@ngyro.com> Date: Thu, 13 Jun 2019 14:09:10 -0400 In-Reply-To: (Robert Vollmert's message of "Thu, 13 Jun 2019 18:11:00 +0200") Message-ID: <87lfy59x2x.fsf@ngyro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Robert Vollmert Cc: 36048@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Robert, Robert Vollmert writes: > Hi Timothy, > > thanks for the detailed feedback, this is very helpful! You=E2=80=99re welcome! > I=E2=80=99ve sent an updated patch addressing some of the concerns, but h= ave > some questions regarding others. (I just realized that the documentation > updates probably anticipate multiple return values.) Yes. >> On 13. Jun 2019, at 04:28, Timothy Sample wrote: >>> + (let-values (((port get-hash) (open-sha256-input-port port))) > >>> + (cons >>> + (read-cabal (canonical-newline-port port)) >>> + (bytevector->nix-base32-string (get-hash))))) > > [=E2=80=A6] > >> Also, I think returning multiple values would be more natural here >> (i.e., replace =E2=80=9Ccons=E2=80=9D with =E2=80=9Cvalues=E2=80=9D). > > I tried building it that way to begin with, but I=E2=80=99m having issues > making it work (nicely, or maybe at all). I think it comes down to > later functions optionally failing with a single #f-value. Judging > by the lack of infrastructure, I imagine functions that return different > numbers of values are not idiomatic scheme. Should this be changed to > return two values (#f #f) on failure? Or to raise an exception and > handle it higher up when we want to ignore a failure? > > Currently, implementing this with values/let-values results in me > doing more or less a combination of let-values and match, at which > point it seems that any potential benefits of using multiple values > as opposed to a pair/list are lost. (There=E2=80=99s no match-values form= is > there?) I=E2=80=99m not sure I understand the problem. Here=E2=80=99s what I had i= n mind: --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=values.patch Content-Description: values diff --git a/guix/import/hackage.scm b/guix/import/hackage.scm index 2853037797..9ba3c4b58e 100644 --- a/guix/import/hackage.scm +++ b/guix/import/hackage.scm @@ -120,8 +120,8 @@ version is returned." (define (read-cabal-and-hash port) "Read a cabal file and its base32 hash from a port." (let-values (((port get-hash) (open-sha256-input-port port))) - (cons (read-cabal (canonical-newline-port port)) - (bytevector->nix-base32-string (get-hash))))) + (values (read-cabal (canonical-newline-port port)) + (bytevector->nix-base32-string (get-hash))))) (define (hackage-fetch-and-hash name-version) "Return the Cabal file and hash for the package NAME-VERSION, or #f on @@ -129,7 +129,7 @@ failure. If the version part is omitted from the package name, then return the latest version." (guard (c ((and (http-get-error? c) (= 404 (http-get-error-code c))) - #f)) ;"expected" if package is unknown + (values #f #f))) ;"expected" if package is unknown (let-values (((name version) (package-name->name+version name-version))) (let* ((url (hackage-cabal-url name version)) (port (http-fetch url)) @@ -141,9 +141,8 @@ the latest version." "Return the Cabal file for the package NAME-VERSION, or #f on failure. If the version part is omitted from the package name, then return the latest version." - (match (hackage-fetch-and-hash name-version) - ((cabal . hash) cabal) - (_ #f))) + (let-values (((cabal hash) (hackage-fetch-and-hash name-version))) + cabal)) (define string->license ;; List of valid values from @@ -318,16 +317,14 @@ symbol 'true' or 'false'. The value associated with other keys has to conform to the Cabal file format definition. The default value associated with the keys \"os\", \"arch\" and \"impl\" is \"linux\", \"x86_64\" and \"ghc\" respectively." - (match - (if port (read-cabal-and-hash port) - (hackage-fetch-and-hash package-name)) - ((cabal-meta . cabal-hash) - (and=> cabal-meta (compose (cut hackage-module->sexp <> - cabal-hash - #:include-test-dependencies? - include-test-dependencies?) - (cut eval-cabal <> cabal-environment)))) - (_ #f))) + (let-values (((cabal-meta cabal-hash) + (if port + (read-cabal-and-hash (canonical-newline-port port)) + (hackage-fetch-and-hash package-name)))) + (and=> cabal-meta (compose (cut hackage-module->sexp <> cabal-hash + #:include-test-dependencies? + include-test-dependencies?) + (cut eval-cabal <> cabal-environment))))) (define hackage->guix-package/m ;memoized variant (memoize hackage->guix-package)) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable As far as I see, this behaves the same as the cons-and-match version. Did I miss something? By the way, you make a good point about =E2=80=9Cmatch-values=E2=80=9D. Th= at would be handy. In general, we love =E2=80=9Cmatch=E2=80=9D in Guile and in Guix in= particular, but multiple values are part of the Scheme standard =E2=80=93 there=E2=80= =99s no reason to avoid them. They are perfect for situations like this in place of wrapping the values up into a pair or list and then immediately unwrapping them. -- Tim --=-=-=--