New features in Hackage 2
Though our main priority has been feature parity so that we can switch over, volunteers have contributed several new features:
Package search: you can search by keywords that appear in the package name, synopsis or description. We expect this will be extend later to include tags, module names, author names, and metric-based ranking.
A new visual theme for the site, using the CSS borrowed from haddock.
Improved security: per-package maintainer groups. Only those users may upload new versions of the package. The server also now uses HTTP digest authentication rather than basic authentication.
Adjusting package dependencies after a release to match reality: some package metadata can be edited after a package tarball is uploaded. In particular the dependency version constraints can be tightened or relaxed. The original tarball is not altered.
Hackage “trustees”: a privileged group of users who help to curate the collection of packages as a whole (or some subset). They can adjust package tags and metadata — including fixing dependencies. The hope is that this will significantly improve the number of packages that build “out of the box”.
Package changelogs, when they are included at top level in the package tarball.
The contents of package tarballs can be browsed online.
User self-registration via email, and self-service password reset. The current policy however is that before a new user can upload packages they must be added to the “uploaders” group by an administrator.
Documentation can be uploaded by any suitably-authorised user, not just a single dedicated documentation build bot. In particular maintainers can upload documentation bundles if the doc build bots fail to do so.
A RESTful API for getting and updating most of the data that the server holds, plus an auto-generated API description / sitemap.
There are also a number of new features that volunteers have partially implemented or that are in need of improvement. These are being tracked on GitHub.
Tags: packages can have arbitrary sets of tags, initially set from the categories in the .cabal file. This should be extended so that we can consolidate tags that should be aliases and tags should be used in the package search. See issue #24 and issue #27.
Reverse dependencies. This feature has been implemented but is currently disabled because it used to much memory. This should be investigated, the data structured adjusted and the feature re-enabled. The number of reverse dependencies should be an important component of a package popularity/quality metric. See issue #40.
Package “candidates”. You may have noticed that package versions are often uploaded in quick succession — sometimes just minutes apart — because a mistake is only noticed after the author uploaded. This feature lets you upload a “candidate”, giving it a URL that others can download from, and gives an opportunity for build bots and documentation builders to try the package out. Once the author is satisfied then they can publish to the main package index. We think this feature is about 90% complete. See issue #41.
Build reporting. There is support for build bots to upload build reports and build logs. This needs to be extended to include the anonymous build reports that cabal-install can generate. This way we can gather huge amounts of data. The goal is to inform users and maintainers about what packages work in what circumstances by digesting this data into useful information. In particular maintainers and trustees can then edit package dependencies to match reality. See issue #44.
All resources in machine readable formats. Many resources have JSON or other machine readable formats, but not yet all. See the api page. This is an easy way to contribute to the development. See issue #42.
Site visual and information design. While we have at least switched to use the haddock “Ocean” theme, there’s a lot more that could be done by someone good at web design. Currently some pages use templates and other pages are generated in code. We should move towards consistently using templates to make it easier to adjust the site. It would also be possible to make more use of client-side technologies, rather than just classic html4 forms. See issue #43.