portability and .cabal files?

[Claus Reinke]

>> i'd much rather have hackage tell me which packages
>> are usable with my platform (build-reports verifying
>> .cabal file accuracy), than tell me how many people
>> on other platforms are using those packages without
>> caring about portability to other platforms!-)
>
> Absolutely, I'd like to see this too. My proposal is along those lines,
> that we use cabal-install to gather test feedback and that hackage
> should collect and summarise that data. It's not trivial however, it
> needs quite a lot of infrastructure.
>
> 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?

note also that i was talking about .cabal files *specifying*
platform-dependencies, and hackage verifying them, not
about hackage inferring platform-dependencies from
build/failure-reports!-)

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

claus