Re: on cabal revisions

[Robert Vollmert]

Hi Timothy,

thanks for your reply.

> On 12. Jun 2019, at 06:54, Timothy Sample <address@hidden> wrote:
> 
> Hi Robert,
> 
> I patched the “cabal-revision” stuff into the build system, so I suppose
> I should weigh in here.  :)
> 
> Robert Vollmert <address@hidden> 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.

[…]

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

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 
>> - 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’m unsure though whether the
snippet approach actually improves things here — probably the refresh
code would see the resulting gexp and not the raw data.

Cheers
Rob