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: remote-repo: hackage.haskell.org:http://hackage.haskell.org/packages/archive 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: /packages/00-index.tar.gz /package/foo-1.0.tar.gz 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. Duncan