[Haskell-cafe] The state of Hackage: what are we doing about it?

[Andrew Coppin]

Don Stewart wrote:
>     http://tinyurl.com/2cqw9sb
>
> Thoughts?
>   

Firstly, it pleases me that somebody is taking this problem seriously 
and looking at it.

Currently all the information displayed on a package page comes from the 
Cabal file. I think it would be useful to be able to retrospectively 
alter certain things. (Information on stability, level of support, and 
platforms known to work / not work are obvious candidates here.) The 
package page really ought to be the central location for saying stuff 
about the package - and that includes information that becomes available 
after the package is released.

We don't seem to have a comprehensive story for bug-tracking. Each 
project or library has their own ad-hoc arrangements. Usually that means 
no bug reporting system at all, although some of the larger projects 
each have their own seperate site. I think there is milage in setting up 
some kind of centralised system. Small projects probably don't merit the 
effort of setting up a whole dedicated tracker, and besides, who wants 
to create user accounts on a dozen different trackers? I'm thinking some 
kind of tracker which tracks bugs for any package on Hackage. Like, as 
soon as you upload a package, people can file bugs against it in one 
central location. (And check whether it's already been filed, for that 
matter...) Of course, it's not much use if it doesn't also notify the 
package author; presumably you have to specify contract details when you 
create a user account or something.

It would also be nice to have a system in place for users to tell 
package authors about possible fixes / enhancements, etc. But given that 
everybody has their own favourit source control system (including NONE 
AT ALL) this isn't particularly easy. I guess we'll leave that for now.

Also, unless I'm missing something, Darcs has a feature to run automated 
tests on commit, but there's no way of including a test framework in 
such a way that Cabal / Hackage knows how to test your package. The most 
it can do is test whether it compiles; it might fail spectacularly when 
actually *run*. (Also, end-users may or may not want this test 
infrastructure when installing a library.)

Ooo, and change logs... There doesn't seem to be any coherant way to 
organise these. OK, so there's a new version of Foo out now. So... 
what's new? Is this a bugfix or does it have new features or just 
tweaked documentation or more QuickCheck properties or...? It looks like 
there ought to be a specific place to record this information.

Documentation is something else worth looking at. Currently the Haskell 
Way(tm) is to have documentation embedded within the source code itself, 
which I've never been fond of. For one thing is makes the source about 
20x bigger and obscures its structure with a lot of comments. But for 
another thing, there's more than one kind of documentation. Haddock 
handles API documentation. It is less than helpful for writing example 
documentation, introductions and tutorials, and all the other kinds of 
library documentation one might want to write. Also, it seems 
unfortunate that you have to edit source code and upload a new version 
of a package just to improve the documentation. What we do NOT want, of 
course, is documentation that's out of sync with the package it's 
supposed to document! Tying the documentation to the source code 
achieves this (mostly), but it seems like there should be a Better 
Way(tm)... I'm not sure what though.

OK, I'm going to stop typing now...