nice new hackage urls

Duncan Coutts duncan.coutts at
Tue Jul 7 07:57:16 EDT 2009

On Tue, 2009-07-07 at 08:41 +0100, Ross Paterson wrote:
> On Sat, Jul 04, 2009 at 06:01:13PM +0100, Duncan Coutts wrote:
> > This made me recall that one place we do still have a special case for
> > the current central hackage server is when we specify the upload and
> > check POST URLs. Currently hackage uses:
> > 
> > /cgi-bin/hackage-scripts/check-pkg
> > /cgi-bin/hackage-scripts/protected/upload-pkg
> > 
> > At the moment, cabal-install just hard codes these URLs when it notices
> > that we're using the main hackage server. When we're using any other
> > server (assumed to be the new hackage-server impl) then we use
> > $serverroot/upload. I'm not sure this is ideal.
> > 
> > So I suggest we find a common standard URL, eg:
> > 
> > $serverroot/packages/upload
> > $serverroot/packages/check
> > 
> > and make the current server use that as an allowable alias for its
> > existing cgi scripts, and adjust cabal-install and the new hackage
> > server to do the same.
> SimonM has added the aliases.

Thanks both.

I now realise we need a bit more :-)

So the issue is that we'd like to be able to specify a server by a
single URL and be able to find everything else relative to that. Ideally
we would do that by some discovery mechanism rather than hard coding
relative URLs into the clients, but in the mean time...

So we want all interesting URLs to be relative to one root. Currently
hackage has two roots '/' and '/packages/archive/'. We find the index
and package tarballs in the second and for other things we've been
moving more towards the main root '/' with things like '/package/foo'.

Currently in the cabal-install config file we use:

and then lookup the 00-index.tar.gz and all the package tarballs
relative to that. So if we try to unify it around a single root '/' then
here's my suggestion:


Again, the principle is that /packages/* are attributes of the
collection as a whole (indexes, stats, reports), where /package/* are
elements of the collection (ie packages).

> Any word on when you'll be ready to take over?

There's been more contributors recently with work on authentication
which is one of the last two features needed for parity. The other being
doc uploads and downloads. I hope we'll be able to polish things off at
the next hackathon and get at least a testing instance running on a
persistent basis, so we can start evaluating migration.


More information about the cabal-devel mailing list