Version 20 (modified by ross@…, 6 years ago)

markup fix

Hackage rough To Do list

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

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?)
  • The package page could maybe have links to packages which depend on it?
  • Searching / querying for a package
    • Generic mechanism that outputs a pretty page for a user to see, or outputs an RSS feed?
    • by name or description
    • 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 Subscriptions (we could add to  Planet Haskell)
    • New uploads (new versions, new packages)
    • generic query mechanism
    • based on tags and / or new uploads since-date, etc.

Auto-building

  • 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.
  • If the directory archive/package/package-id.misc/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 in a known place, archive/package/latest.misc/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).
  • Running arbitrary code may be unavoidable if we rely on Cabal to run Haddock: pre-requisite packages must be configured, built, haddocked and installed (in a local package database). This will probably have to be done in a chroot jail. The resulting output will contain local filenames, which will have to be mangled to point to the standard location.
  • 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.