portability and .cabal files?
duncan.coutts at worc.ox.ac.uk
Mon Nov 26 20:15:36 EST 2007
On Tue, 2007-11-27 at 00:32 +0000, Claus Reinke wrote:
> > I opened a bug on it the other day:
> > http://hackage.haskell.org/trac/hackage/ticket/184
> yes, that sounds promising. but then i recalled my
> standard answer when microsoft asks me to let them
> know the details about how acrobat plugin or ghc or
> whatever have crashed: it is "no", plain and simple.
> so, perhaps promising in theory, but not in practice?
Privacy is obviously of vital importance as I noted.
> note also that i was talking about .cabal files *specifying*
> platform-dependencies, and hackage verifying them, not
> about hackage inferring platform-dependencies from
Well, you might have access to Windows, Mac, Linux and Solaris boxes but
I certainly do not. Most other package developers do not either. So they
cannot specify anything except by feedback from people who do have
access to those platforms.
(As it happens I'm pretty lucky and do have access to Linux and logins
to Solaris and Windows servers. But Macs are pretty expensive and the
department don't have any Mac servers.)
> btw, i haven't followed developments closely but,
> at various points in the past, we have talked about
> a 'runhaskell Setup check' that would help to check
> conformance to some minimal guidelines before
> publishing a cabal package, such as:
> - is there a README file? this should be a must,
> and there are too many packages on hackage
> that hardly tell me anything about what they do,
> nor how or whether they build on my platform
> (the how has been improving with new .cabal
> fields, but those fields aren't used everywhere..)
> - is there a build-tools field? if there is no README,
> this is a must have.
> - are platform dependencies specified? here cabal
> would need to prescribe a standard way to
> specify these in the .cabal file
> - are there no open-ended dependency versions?
> (cf package versioning discussion)
> - etc.
> if there was a 'check' command, writing the
> documentation for it would clarify many of the
> currently implicit conventions of writing .cabal
> files. and if running 'check' would be a pre-requisite
> for publishing on hackage, more packages would
> make good use of those conventions.
> just another suggestion for the haskell cabal folks!-)
Yes, when we thought about this before we all agreed it'd be a nice
thing. It'd be even nicer if someone had the time to implement it.
Hackage already does some additional checks but letting developers run
those checks on their own machines and extending the set of checks would
Would you like to start by filing your list of suggested checks in a
trac feature request?
I think this kind of non-core feature would be better to go in the
cabal-install tool, though obviously using the Cabal library api.
More information about the cabal-devel