From: Robert Vollmert <rob@vllmrt.net>
To: guix-devel@gnu.org
Subject: on cabal revisions
Date: Tue, 11 Jun 2019 22:56:41 +0200 [thread overview]
Message-ID: <BCFE219F-85DB-4BDF-9BD5-F5BF5B42E3B0@vllmrt.net> (raw)
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
next reply other threads:[~2019-06-11 21:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-11 20:56 Robert Vollmert [this message]
2019-06-12 4:54 ` on cabal revisions Timothy Sample
2019-06-13 11:46 ` Robert Vollmert
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=BCFE219F-85DB-4BDF-9BD5-F5BF5B42E3B0@vllmrt.net \
--to=rob@vllmrt.net \
--cc=guix-devel@gnu.org \
/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).