Or you can browse the full list of packages
About this Hackage instance
This is a test instance of the new implementation of the Hackage server (aka "Hackage 2"). For details about Hackage in general, see the existing server.
We are using this instance for a public alpha test. You are welcome to take part. There are instructions below for how to configure cabal to point to this server.
Please don't post it to reddit just yet! During this early phase of the alpha testing we would prefer you not to advertise it too widely. We would prefer initially not to have too many users all reporting the same set of known problems. We will publicise it more widely when we are into the beta phase.
We expect to have a couple months during the alpha and beta-phases where the two servers run side by side.
Note: we are mirroring packages from the old server (currently every 30min) so it is suitable to use as your main hackage server with some caveats: because we are allowing package authors to upload (as well as the mirroring) then you may find a slightly different set of packages on this server.
If you are a package author then you are welcome to poke about and upload packages. We have imported user accounts from the old server. During this phase of the alpha testing we invite you to report your comments to the cabal-devel mailing list.
Note: before we do the final switchover we will delete everything from this test instance and do a fresh import from the existing hackage server.
Edit your ~/.cabal/config file. Comment out the existing remote-repo line near the top of the file and add in a new one like this:
--remote-repo: hackage.haskell.org:http://hackage.haskell.org/packages/archive remote-repo: new-hackage.haskell.org:http://new-hackage.haskell.org/
The new implementation is now more-or-less at feature parity with the old server.
We have imported all the data from the old server (except package download counts). Currently we do not have a documentation builder client running, but one has been developed, it's just a matter of setting that up.
Support from the IHG
You'll not have failed to notice that Hackage 2 has been "under development" for rather a long time. It has suffered from a lack of volunteer time (particularly lack of a main maintainer to review patches and encourage other contributors). The "first 90%" was done by volunteers, particularly Matthew Gruen for his GSoC project.
The Industrial Haskell Group (a consortium of companies that rely on Haskell) decided to support the "last 90%" to get Hackage 2 to a state where it can actually be used and to switch over from the old implementation. Well-Typed have been doing the development work on Hackage 2 on behalf of the IHG for the last several months. The goal has been to get it deployed, rather than worrying too much about the new features. We believe that once it is actually up and running, that the community will be more interested in helping improve and add features.
If your company is interested in supporting work such as this, please consider joining the IHG.
Though our main priority is feature parity so that we can switch over, there are some new features:
Per-package maintainer groups, and only those users may upload new versions of that package.
Can serve package changelogs (when they are included in the package tarball)
Can browse the contents of package tarballs online
User self-registration via email (and similarly for password reset)
Documentation can be uploaded by any suitable authorised user, not just a single dedicated doc build bot. In particular maintainers can upload documentation bundles if the doc build bots fail to do so.
Simple package search. We can search by package name and by keywords that appear in the package description.
An always-up-to-date server api / sitemap
There are also a number of features that are partially implemented or are in need of improvement
Trustees concept. In addition to package maintainers, hackage trustees are people who can help curate a collection of packages. While they cannot upload new versions of packages directly, the intention is that they can edit package metadata, including adjusting dependencies to match reality. Currently the only things they can edit are package tags and upload documentation.
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 the same, and tags should be used in the package search.
Reverse dependencies. This feature was implemented but is currently turned off 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.
Download counts. This feature exists but it will need some attention because it will not scale to large numbers of packages and long periods of time. Again, download counts are an important component of a package popularity/quality metric.
Package search. This exists but should be extended to search more than just name and description. It should also include tags. For ranking results it should use a package metric (based initially on download counts and reverse dependencies).
Package "candidates". You have probably seen 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 doc builders and build bots to try the package out. Once the author is satisfied then they can publish to the main package index. This feature is about 95% complete (we think).
Editing package metadata after release. One of the problems we face with large sets of packages is making sure the dependencies are accurate. By allowing them to be edited after a release, we can adjust them to match reality, which will help cabal-install to do the right thing. For example we could tighten bounds if we find a package breaks with some versions of a dependency or relax upper bounds to work with new versions of dependencies.
Build reporting. There is partial support for uploading build reports and build logs. This needs to be extended and should include anonymous build reports that the cabal-install client can generate. This way we can gather huge amounts of data on what packages work in what circumstances. We can use that to help inform maintainers and users and to edit package dependencies to match reality.
All resources in machine readable formats. This is incomplete. Many resources have json or other machine readable formats, but not all yet. See the api page (which itself has a json version). This is an easy way to contribute to the development.
Site visual and information design. While we have at least switched it all to use the haddock "Ocean" theme, there's a lot more that could be done by someone good at web design. The pages are currently constructed of a mixture of templates and pages generated in code. We should try to do that consistently with templates and make it easier to adjust the site. It should also be possible to do more JS stuff, rather than classic html4 POST forms.
darcs get http://code.haskell.org/hackage-server
While the code is in darcs at the moment (as that was quicker for the people who were working on it recently) the plan is to move it to github at some point during the beta.
We'd like to make it as simple as possible for anyone to set up a Hackage server.
Getting the raw data
There are a few other package indices:
- All tags
- All packages by name, with tags
- All packages with reverse dependencies (this feature is currently not enabled)
- All packages by download (since old download data isn't imported, this will look somewhat barren)
- All packages with preferred versions
- All deprecated packages
- All candidate packages