unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* on cabal revisions
@ 2019-06-11 20:56 Robert Vollmert
  2019-06-12  4:54 ` Timothy Sample
  0 siblings, 1 reply; 11+ messages in thread
From: Robert Vollmert @ 2019-06-11 20:56 UTC (permalink / raw)
  To: guix-devel

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2019-06-16  8:00 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-06-11 20:56 on cabal revisions Robert Vollmert
2019-06-12  4:54 ` 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

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