From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Vollmert Subject: Re: on cabal revisions Date: Thu, 13 Jun 2019 13:46:03 +0200 Message-ID: References: <87v9xbmmid.fsf@ngyro.com> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:50775) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hbOBN-0006bK-C7 for guix-devel@gnu.org; Thu, 13 Jun 2019 07:46:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hbOBM-00071e-1A for guix-devel@gnu.org; Thu, 13 Jun 2019 07:46:17 -0400 Received: from mx2.mailbox.org ([80.241.60.215]:10068) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hbOBL-0006zH-Ny for guix-devel@gnu.org; Thu, 13 Jun 2019 07:46:15 -0400 In-Reply-To: <87v9xbmmid.fsf@ngyro.com> 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" To: Timothy Sample Cc: guix-devel@gnu.org Hi Timothy, thanks for your reply. > On 12. Jun 2019, at 06:54, Timothy Sample wrote: >=20 > Hi Robert, >=20 > I patched the =E2=80=9Ccabal-revision=E2=80=9D stuff into the build = system, so I suppose > I should weigh in here. :) >=20 > Robert Vollmert writes: >=20 >> Hello all, >>=20 >> I have a question regarding how cabal revisions are handled >> for haskell packages. Namely, would it make sense / is it >> possible to make the revised cabal file part of the source >> field in the package definition? >=20 > Yes it makes sense, and yes it is possible. This is something I = wanted > to do before, but I wasn=E2=80=99t sure how. The only idea I had was = to make a > new download method, but that=E2=80=99s a very heavy solution for such = a simple > task. [=E2=80=A6] >> Alternatively, could this be achieved through the snippet field? >> I couldn=E2=80=99t work out how, and none of the uses of snippet that = I >> found used any file input. >=20 > There is a way to do it through the mighty power of gexps! Behold: >=20 > (origin > (method url-fetch) > (uri (string-append "https://hackage.haskell.org/package/" > "tree-diff/tree-diff-0.0.1.tar.gz")) > (sha256 > (base32 > "049v44c520jy3icxlnrvbdblh3mjmvd7m6qmkzxbzkf02x63xqmz")) > (snippet > #~(copy-file > #+(origin > (method url-fetch) > (uri (string-append = "https://hackage.haskell.org/package/" > "tree-diff-0.0.1/revision/4.cabal")) > (sha256 > (base32 > = "1rqxxyj6hqllahs11693g855cxz8mgnb490s7j1ksd300i5xgjsp"))) > "tree-diff.cabal"))) >=20 > (I=E2=80=99m constantly amazed at how useful, composable, and = empowering gexps > are.) This could be cleaned up with some procedures and made just as > nice as the current setup. What do you think? Lovely, thanks. The following works for me: (source (origin (method url-fetch) (uri (string-append "https://hackage.haskell.org/package/tree-diff/tree-diff-" version ".tar.gz")) (sha256 (base32 "049v44c520jy3icxlnrvbdblh3mjmvd7m6qmkzxbzkf02x63xqmz")) (snippet (snippet-hackage-revision "tree-diff" version "4" (base32 "1rqxxyj6hqllahs11693g855cxz8mgnb490s7j1ksd300i5xgjsp"))))) with (define* (snippet-hackage-revision hackage-name version revision hash) #~(copy-file #+(origin (method url-fetch) (uri (string-append "https://hackage.haskell.org/package/" hackage-name "-" version "/revision/" revision ".cabal")) (sha256 hash)) (string-append #+hackage-name ".cabal"))) Would this be a worthwhile change? What would be a good place (and name) for snippet-hackage-revision? One disadvantage that I see is that it moves the revision information from plain data in the arguments field to a rather opaque code snippet. >> (My reasons why using the source field instead of the argument >> field might be nicer: >> - all sources in one place >> - less special-casing for the haskell build system >> - simpler=20 >> - maaaybe a useful abstraction that allows simplifying things >> like patching, too) I remembered one more: guix refresh. As far as I understand, it works only on the level of the source field, thus having the revision there would help make it revision-aware. I=E2=80=99m unsure though whether the snippet approach actually improves things here =E2=80=94 probably the = refresh code would see the resulting gexp and not the raw data. Cheers Rob