From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timothy Sample Subject: Re: on cabal revisions Date: Wed, 12 Jun 2019 00:54:34 -0400 Message-ID: <87v9xbmmid.fsf@ngyro.com> References: 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]:51460) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1havKv-00084K-OJ for guix-devel@gnu.org; Wed, 12 Jun 2019 00:58:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1havHS-0003oV-W8 for guix-devel@gnu.org; Wed, 12 Jun 2019 00:54:40 -0400 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:46175) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1havHS-0003o4-Lu for guix-devel@gnu.org; Wed, 12 Jun 2019 00:54:38 -0400 In-Reply-To: (Robert Vollmert's message of "Tue, 11 Jun 2019 22:56:41 +0200") 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, I patched the =E2=80=9Ccabal-revision=E2=80=9D stuff into the build system,= so I suppose I should weigh in here. :) Robert Vollmert writes: > Hello all, > > 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? 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 ma= ke a new download method, but that=E2=80=99s a very heavy solution for such a si= mple task. > Summary for non-haskell-experts: A hackage package of > a given version can have metadata revisions that are applied > to its cabal file, but not the source tarball itself. > > Consider e.g. the package utf8-string-1.0.1.1, > > http://hackage.haskell.org/package/utf8-string-1.0.1.1 > > The source tarball includes a file utf8-string.cabal, which > is =E2=80=9Crevision 0=E2=80=9D. The latest revision of utf8-string-1.0.1= .1 > is revision 3, with cabal file at > > http://hackage.haskell.org/package/utf8-string-1.0.1.1/revision/3.cabal > > Typically, such revisions update the version bounds on > dependencies; e.g. a package might not build against the > current guix set of haskell packages at revision 0, but might > build at a higher revision because some restrictive bound has > been lifted. > > > Currently, haskell-build-system supports cabal revision via > an argument field, e.g.: > > (arguments > `(#:cabal-revision > ("3" "02vhj5gykkqa2dyn7s6gn8is1b5fdn9xcqqvlls268g7cpv6rk38"))) > > This works; I=E2=80=99ve posted a patch > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D36048 > > to make guix import hackage aware of this so that it doesn=E2=80=99t > import stale version by default. That=E2=80=99s fantastic, thanks! I see it hasn=E2=80=99t been reviewed ye= t =E2=80=93 I=E2=80=99ll try and take a look tomorrow. > However, I was thinking that it might be better to have this > variant cabal file be part of the source field of the package > definition. Is there a nice way to do that? > > It feels like this might be hacked in via the patching mechanism, > but that feels dirty. I=E2=80=99d rather patching be generalized to > something that both supports applying a patch (from a local file > or a URL), or copying a file. (Or unpacking another tar ball to > some subdirectory, for that matter.) > > 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. There is a way to do it through the mighty power of gexps! Behold: (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"))) (I=E2=80=99m constantly amazed at how useful, composable, and empowering ge= xps are.) This could be cleaned up with some procedures and made just as nice as the current setup. What do you think? > What I=E2=80=99m imagining is something roughly like this: > > (source > (origin > (method url-fetch) > (uri =E2=80=9Chttps://hackage.haskell.org/package-sources.tar.gz= =E2=80=9D)) > (sha256 =E2=80=A6)) > (origin > (destination =E2=80=9Cpackage.cabal=E2=80=9D) > (method url-fetch) > (uri =E2=80=9Chttps://hackage.haskell.org/package/1.cabal=E2=80=9D) > (sha256 =E2=80=A6))) > > probably with some way to specify how the sources should be > combined, by default unpacking over the previous result > sequentially. Would that be possible? A good idea even? This makes sense, but I=E2=80=99m not sure it=E2=80=99s a common enough use= case to warrant a specialized interface. Besides these Cabal revisions, only a handful of packages (that I=E2=80=99ve seen) need to download extra non-pat= ch stuff. Some packages have external test suites, for instance. Since it would be mostly just the Haskell packages that would use it, and we already have one and a half Cabal revision interfaces, I don=E2=80=99t see a strong need. That being said, I don=E2=80=99t know the package collection = as well as many others here, so maybe I=E2=80=99ve missed something. > (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) > > > What do you think? I think the first three points you make are good ones! I=E2=80=99m less su= re about that last one, though. :) -- Tim