Re: on cabal revisions

[Timothy Sample]

Hi Robert,

Robert Vollmert <address@hidden> writes:

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

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 “modules”
field in the “origin” record, making it a little more verbose.

To be clear, what I mean is to write

    (snippet
     #~(snippet-hackage-revision "tree-diff" version "4"
         (base32
          "1rqxxyj6hqllahs11693g855cxz8mgnb490s7j1ksd300i5xgjsp")))

and then put “snippet-hackage-revision” somewhere in “(guix build ...)”.
This way, at least in most cases, you could get the Cabal revision if
you had nothing but an “origin” record.  I’m not sure 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 
>>> - 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.

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