[Haskell-cafe] The state of Hackage: what are we doing about it?
andrewcoppin at btinternet.com
Wed Jun 2 12:17:37 EDT 2010
Don Stewart wrote:
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...
More information about the Haskell-Cafe