From: Robert Vollmert <rob@vllmrt.net>
To: Timothy Sample <samplet@ngyro.com>
Cc: guix-devel@gnu.org
Subject: Re: on cabal revisions
Date: Thu, 13 Jun 2019 13:46:03 +0200 [thread overview]
Message-ID: <AFEABE04-AA6D-412D-9927-40A11F0611C9@vllmrt.net> (raw)
In-Reply-To: <87v9xbmmid.fsf@ngyro.com>
Hi Timothy,
thanks for your reply.
> On 12. Jun 2019, at 06:54, Timothy Sample <samplet@ngyro.com> wrote:
>
> 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.
[…]
>> 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
next prev parent reply other threads:[~2019-06-13 11:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-11 20:56 on cabal revisions Robert Vollmert
2019-06-12 4:54 ` Timothy Sample
2019-06-13 11:46 ` Robert Vollmert [this message]
2019-06-13 14:25 ` Timothy Sample
2019-06-14 14:30 ` Robert Vollmert
2019-06-14 15:36 ` Timothy Sample
2019-06-14 20:24 ` Ricardo Wurmus
2019-06-16 8:00 ` haskell package organization (Re: on cabal revisions) Robert Vollmert
2019-06-14 20:28 ` on cabal revisions Ricardo Wurmus
2019-06-15 9:02 ` reproducibility and bootstrapping in mid 2019 (was Re: on cabal revisions) Giovanni Biscuolo
2019-06-14 20:12 ` on cabal revisions Ricardo Wurmus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AFEABE04-AA6D-412D-9927-40A11F0611C9@vllmrt.net \
--to=rob@vllmrt.net \
--cc=guix-devel@gnu.org \
--cc=samplet@ngyro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).