Hackage rough To Do list

A  basic version of the Hackage Database is now online. Below is a list of items that still need to be done. FIX: Add link to getting and building source code?

• Searching / querying for a package
  • Generic meachanism that outputs a pretty page for a user to see, or outputs an RSS feed?
  • by name or description
  • by Hoogle? :)
  • by tags (below)
• RSS Subscriptions (we could add to  Planet Haskell)
  • New uploads (new versions, new packages)
  • generic query meachanism
  • based on tags and / or new uploads since-date, etc.
• Show who uploaded package and when
• auto building (see below)
• Haddock (see below)
• Darcs (and other VC) integration (see below).
• The page for a package could include information from standard README, INSTALL, NEWS etc files. Those files could contain wikitext-like markup.
• Syntax highlighted source code with links from haddock directly to function definitions
• The package page could have links to other versions of the same package, and maybe to packages which depend on it?
• Generate change information between package versions: functions added/removed/changed, modules added/removed.
• When a new version of a package is uploaded, generate a list of packages that will be affected and possibly broken by the upload, and notify the uploader, and test the builds.
• a command-line tool for uploading packages remotely via the CGI interface.

Auto-building

• Are dependencies available in Hackage?
• Test with different compiler & versions, report which ones work
• Build packages
• Build Haddock docs (see below)
• Run test suites

Darcs integration

• Need Cabal field for darcs repository, perhaps "repository: darcs:http://darcs.haskell.org/ghc",
• should we also have a link to a URL for browsing the repo, that would eg. point to the darcsweb?
• should there also be a way to jump to the repo browser for the tag of this particular version, for viewing the change log?
• Problem: some repositories contain multiple packages.

Rough plan for Haddock

• The generated haddock should link to types, modules etc. in the packages which it depends on.

• The Haddock for the latest version of each package is in a known place.
• Links across packages always point to the latest version of the target package. This way we don't have to worry about re-haddocking dependent packages whenever a package at the bottom of the tree is updated. Some dependencies may go wrong, if a package depends on a specific version of another package for example, but this way is simple at least.

• Avoiding running arbitrary code to generate the Haddock: if we restricted ourselves to packages that just use the simple build system and only Haddock those, then we don't need to worry about arbitrary code. But some important packages use autoconf, and we won't be able to do those. Also, we can't tell whether a package uses the simple build system or not: we need the field in the .cabal file to tell us (see previous discussion).

Classifying packages

Several people felt that a collection of categories, even overlapping, was too inflexible, and that we should use a system of facets and tags, as in  debtags. A facet is a dimension of classification; a tag is a value for a facet. A package would be described by a set of facet::tag pairs.

• these could be used in a more sophisticated search interface.
• we'd probably want a registry of facets and tags.
• some facets describe packages, e.g. field, interface, use, while others describe particular versions, e.g. builds-with, tested-with.
• we'd want to be able to attach at least some facet-tag pairs some time after uploading (e.g. builds-with::ghc-19.2). Since packages may not be updated frequently, we'd probably want to add others too.