on cabal revisions

[Robert Vollmert <rob@vllmrt.net>]

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?


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.


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.

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?


(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?

Robert