cmd/go: remove special handling of launchpad.net #11436

Closed
mwhudson opened this Issue Jun 27, 2015 · 6 comments

Comments

Projects
None yet
4 participants
Contributor

mwhudson commented Jun 27, 2015

As Launchpad now supoprts both git and bzr for codehosting, the currently handling of launchpad.net import paths in cmd/go is not sufficient. Rather than complicating it further, we're going to add appropriate tags to the appropriate pages on launchpad (https://bugs.launchpad.net/launchpad/+bug/1465467). When that's done, we can just delete the code in cmd/go. It would be nice to get this into 1.5.

@bradfitz bradfitz added this to the Go1.5Maybe milestone Jun 27, 2015

Owner

bradfitz commented Jun 27, 2015

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

/cc @rsc for decision.

Contributor

rsc commented Jun 29, 2015

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.

Contributor

mwhudson commented Jun 29, 2015

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.

Contributor

mwhudson commented Jul 14, 2015

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.

Contributor

rsc commented Jul 14, 2015

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.

@rsc rsc modified the milestones: Go1.5, Go1.5Maybe Jul 20, 2015

@rsc rsc closed this in 669f5be Jul 28, 2015

@gopherbot gopherbot locked and limited conversation to collaborators Aug 5, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.