From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timothy Sample Subject: Re: on cabal revisions Date: Thu, 13 Jun 2019 10:25:55 -0400 Message-ID: <87r27xa7f0.fsf@ngyro.com> References: <87v9xbmmid.fsf@ngyro.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:470:142:3::10]:39159) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hbQg7-0000em-RA for guix-devel@gnu.org; Thu, 13 Jun 2019 10:26:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hbQg3-0002NL-TY for guix-devel@gnu.org; Thu, 13 Jun 2019 10:26:09 -0400 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:43329) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hbQfx-0002BJ-NN for guix-devel@gnu.org; Thu, 13 Jun 2019 10:26:06 -0400 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: Robert Vollmert Cc: guix-devel@gnu.org Hi Robert, Robert Vollmert writes: > 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 syst= em, 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. True, but we could move the procedure to the build side, and then the gexp would be simple enough to understand mechanically. The downside to this is that we would (probably) have to put something in the =E2=80=9Cmodu= les=E2=80=9D field in the =E2=80=9Corigin=E2=80=9D record, making it a little more verbo= se. To be clear, what I mean is to write (snippet #~(snippet-hackage-revision "tree-diff" version "4" (base32 "1rqxxyj6hqllahs11693g855cxz8mgnb490s7j1ksd300i5xgjsp"))) and then put =E2=80=9Csnippet-hackage-revision=E2=80=9D somewhere in =E2=80= =9C(guix build ...)=E2=80=9D. This way, at least in most cases, you could get the Cabal revision if you had nothing but an =E2=80=9Corigin=E2=80=9D record. I=E2=80=99m not su= re how important this is, though (see below). >>> (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 ref= resh > code would see the resulting gexp and not the raw data. This is a very good point! Unfortunately, AFAICT, the refresh mechanism only works on the level of versions. It has no support for automated patches or snippet changes. It looks like updating the Cabal revision using the refresh script would require one or two far-reaching changes. Are there other package repositories that use a release-with-patches style? Having another example would make it easier to design at the right level of abstraction. Now I think that we should have a good plan for refreshing before making a bunch of changes to the Cabal revision stuff. Otherwise, we might have to change everything again if and when we make refreshing work. Thoughts? -- Tim