x/tools/cmd/goimports: always choose internal copy over outer copy

[rsc]

If someone is working in a tree where they have gone to the trouble to vendor a package, as long as the vendored copy is visible (not blocked by internal) we should make sure the vendored copy is always preferred. Otherwise goimports may hurt more than it helps in these situations.

Once there is a standard config file explaining what has been vendored, goimports could just read it and when it wants to use X but there's a vendored copy visible, use the vendored copy instead.

This came up in a private discussion with an external project about vendoring.

[thockin]

More than this, I want goimports to fail rather than choose a non-vendored option. This is,IMO, the strength of the model wherein I change GOPATH - goimports and every other tool simply do not know about the existence of non-vendored anything.

I'd rather see the go tool learn to read a local .gopath_override file or something, which I could check in with the repo, and then use non-rewriting vendoring.

[mdwhatcott]

Just curious, will this feature be finished by the time go 1.6 is released? @rsc @bradfitz

[rsc]

I have a pending CL I need to finish, once hotter fires are out.

[mdwhatcott]

Understood

[zellyn]

Is this fixed by https://go-review.googlesource.com/#/c/17728/?

[bradfitz]

I think this has been fixed, yes, by various recent CLs including that referenced one. We always prefer the shortest import path, after de-vendorizing the import path (from the relative path on disk from the top of $GOPATH)