I'm personally okay with deleting code & special cases, but:

/cc @rsc for decision.

Thank you for adding the meta tags on launchpad.net itself. Removing a special case sounds great. Note that people using Go 1.4 and earlier will still not be able to take advantage of the tags, because the name pattern will trigger. That is, I believe we have to remove the special case code in order for the tags to do anything useful for you (in particular, for them to resolve the problem that some repos are now git). So once the tags are deployed let us know and we'll gladly rip the special case out (or just send a CL).

Thanks.

Yes, that matches my understanding too. Will send a CL as soon as it's deployed (soon, I hope); we'll see then if it's in time for 1.5 I guess.

Argh. Launchpad has deployed meta tags on project and series pages, but it's not enough to remove the all special casing in the go tool, because the go tool has support for go getting 'within' a repo:

import "launchpad.net/project/series/sub/directory"
import "launchpad.net/~user/project/branch/sub/directory"

and also for handling the fact that import "launchpad.net/project/foo" is ambiguous, as explained in a comment:

// launchpadVCS solves the ambiguity for "lp.net/project/foo". In this case,
// "foo" could be a series name registered in Launchpad with its own branch,
// and it could also be the name of a directory within the main project
// branch one level up.

I'm not sure what to do about this :( I don't think these features are used very frequently.

I guess we could add /more/ special casing so that 1) "launchpad.net/project" (and that path only) is probed for a meta tag, 2) add handling for git branches (which have different enoughs URLs that a regex can know if git should be used aiui).

Feels too hard for 1.5 somehow.

That's too bad. Maybe we should put this off until Go 1.6?

One thing we could do to try to enable a transition in the next six months
would be to make launchpad.net import paths prefer the tags
but fall back to the old logic. That would let launchpad.net fix the
problem and the go command would follow along.

I sent you this idea in CL 12143. If you think it is useful, we can do it.
Otherwise we can leave all this for Go 1.6.

CL https://golang.org/cl/12143 mentions this issue.