Hackage rough To Do list

A  basic interface to the Hackage Database is now online. To get the source:

• darcs get  http://darcs.haskell.org/hackage-scripts

Below is a list of items that still need to be done.

Package display

• Show who uploaded package and when
• 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. (Or haddock markup, since we already have to parse descriptions? Or HTML fragments?) cf  hask-home.
• The package page could maybe have links to packages which depend on it?

Queries

• words in synopsis or description
• package name
• module name
• exported names
• author / maintainer / uploader
• ranges of upload date
• by Hoogle? :)
• by tags (below) ?

Uploads

• auto building (see below)
• Haddock (see below)
• 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.
• RSS feed could distinguish new packages from upgrades

Auto-building

• Test with different compiler & versions, report which ones work
• Build packages
• Build Haddock docs (see below)
• Run test suites
• Record feedback from users' cabal-install runs?

Should building happen during upload, between upload and arriving in the archive, or later?

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.
• If the directory archive/package/version/doc/html exists, the package script renders exposed module names as links to the documentation for the corresponding modules.
• The Haddock for the latest version of each package is to be placed at a known location, archive/package/latest/doc/html, a symbolic link to one of those directories.
• 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 (the new Build-Type field).
• We could use Cabal to build the Haddock docs, but then:
  • Prerequisite packages must be configured, built, haddocked and installed (in a local package database), so we would not be able to avoid running arbitrary code (and we might as well build and install this package too). To be safe, this could be done in a chroot jail.
  • The resulting haddock output will contain local filenames, which will have to be mangled to point to the standard location. Alternatively we could tweak the haddock-html field of each .installed-package-info prior to installation.
• Syntax highlighted source code with links from haddock directly to function definitions?

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.

Multiple categories should be enough for now, though.

Gateways to other packaging systems

Each of these is probably best done by someone familiar with a particular packaging system.