Re: on cabal revisions

[Timothy Sample <samplet@ngyro.com>]

Hi Robert,

I patched the “cabal-revision” stuff into the build system, so I suppose
I should weigh in here.  :)

Robert Vollmert <rob@vllmrt.net> 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’t sure how.  The only idea I had was to make a
new download method, but that’s a very heavy solution for such a simple
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 “revision 0”. 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’ve posted a patch
>
>  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36048
>
> to make guix import hackage aware of this so that it doesn’t
> import stale version by default.

That’s fantastic, thanks!  I see it hasn’t been reviewed yet – I’ll 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’d 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’t 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’m 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?

> What I’m imagining is something roughly like this:
>
>    (source
>      (origin
>        (method url-fetch)
>        (uri “https://hackage.haskell.org/package-sources.tar.gz”))
>        (sha256 …))
>      (origin
>        (destination “package.cabal”)
>        (method url-fetch)
>        (uri “https://hackage.haskell.org/package/1.cabal”)
>        (sha256 …)))
>
> 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’m not sure it’s a common enough use case to
warrant a specialized interface.  Besides these Cabal revisions, only a
handful of packages (that I’ve seen) need to download extra non-patch
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’t see a
strong need.  That being said, I don’t know the package collection as
well as many others here, so maybe I’ve 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 
> - 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’m less sure
about that last one, though.  :)


-- Tim