launchpad-users team mailing list archive

[Andrew Bennetts <andrew.bennetts@xxxxxxxxxxxxx>]

Monty Taylor wrote:
[...]
> Honestly, any instructions that include:
> 
> - just edit your ____ and remove the line that says ____ and you should
> be fine
> or
> - just generate a new SSH key
> 
> when we're talking about grabbing a copy of publicly available code are
> too much. Surprisingly many people don't even know how to make their
> first SSH key (although I find that sad) and they shouldn't have to
> clear that hurdle to get a copy of something. What's more likely to
> happen is that they will just give up.

Yes, those instructions are poor, and we should fix the bug that causes
people to need them.  However, the instructions today are one step:

  * do “bzr co lp:foo”

The problem occurs when people add “bzr launchpad-login something” to those
instructions even when they can't login to the codehosting service from that
system.  That then triggers the bug that bzr will try SSH only, even if it
doesn't work.  

If you don't have a bzr launchpad-login set, then lp: URLs will be fetched
over HTTP.  I just tried “bzr co lp:testtools” without a Launchpad login
set, and it fetched over HTTP for me (using bzr 1.13.1, but I don't think
this has changed recently).

I *think* the only time that it would fail without a login set is for
private branches (e.g. embargoed security fixes) that are only accessible to
some people, which requires accessing them via authenticated SSH rather than
anonymous HTTP.  That's reasonable; if you need to login to access a branch,
then you need to login :)  Those branches are pretty rare, though.

> bzr prints an error here ... it would be great if the exception could be
> caught and another transport be tried - or that http was the default for
> all fetching operations given an lp: transport perhaps? Is ssh quicker
> for some reason for this?

SSH is quicker because it has the smart server, and currently the
bazaar.launchpad.net HTTP service doesn't.  We should fix that.

The other difficulty IIRC is that at the time in bzrlib that a lp: URL is
resolved into a transport we don't yet know if we'll want to do write
operations on that transport or only read ones.  I don't think this is an
insurmountable challenge, but it's not a trivial fix either.  (And ideally a
“bzr push lp:foo/...” would give a “You must 'bzr launchpad-login' to push
to lp:foo/...” message rather than an ugly TransportNotPossible or
PermissionDenied error.)

-Andrew.