[RFC] lp: URLs as a directory service?

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> Aaron Bentley wrote:
> One of the reasons to delay resolution of lp:foo is because of filenames.
> 
> So that doing "bzr branch lp:project" creates a directory named
> "project" rather
> than redirecting to http://bazaar.launchpad.net/~project/project/trunk and
> creating a directory named 'trunk'.

The use of generic names like "trunk" is a problem for Bazaar generally.
   I think we need a better solution than having it work nicely for only
the lp transport.

There have also been cases where the branch name wasn't suitable for
use, e.g. when doing "bzr branch bzr-gtk ~/.bazaar/plugins/"

> I'm not terribly concerned about having get_transport() do a lookup, as
> long as
> it only does it when things match.

Absolutely.  My plan was to have directory services register prefixes,
then only use the directory service when that prefix matched.

> I'm not sure what URL manipulations you are thinking of.

I'm thinking of opening containing directories.  It doesn't work
properly with the lp transport, leading to bugs like this 181945 ("bzr
pull lp:upstart fails")

I would like to fix this by doing:
location_transport = transport.get_transport(url)
parent = location_tranport.clone('..')
parent.get(parent.relpath(location_transport.base))

> So maybe more
> of an
> understanding about what you find lacking in our current system would be
> good.

I think that the launchpad transport is more complicated than we need
and that its behavior is more surprising than we would want.  And since
it's a one-off, it doesn't lend itself to supporting other directory
services.

Instead of having to deal with the possibility that anywhere in the code
we might be handed a transport that's not a real transport, we can just
deal with lookups in a single codepath.

I'm also expecting future bugs where the lp URL is stored and used
inappropriately, and where changes in the protocol of the resolved
location lead to problems.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHvHde0F+nu1YWqI0RAvggAJ97bv4Tl988kxmchegFb5UDqUApdQCfelmG
li6dZqOPwob4IGYjHOucrQY=
=SeqP
-----END PGP SIGNATURE-----