x/tools/cmd/goimports: support vendor directories

[cespare]

#12278 was originally about this, but was changed to be about go/build.

go/build and x/tools/go/loader now know about vendor directories, but there is more work to do to make goimports add the correct paths.

When working on $GOPATH/src/a that vendors b, instead of adding the (disallowed) import "a/vendor/b", goimports should add "b".

[FiloSottile]

https://go-review.googlesource.com/#/c/17728/

[termie]

excited about this feature landing :) (trying to move a bunch of code to subpackages)

[termie]

just mirroring here in case people don't look at the gerrit review, here's a patch on top of that review that gets goimports and vim-go working together again https://gist.github.com/termie/34326bd29e89565c95fa

[ottob]

Thanks for the patch @termie it works fine for me.

[pwaller]

This may be a duplicate of #10339.

[cespare]

@pwaller not quite. #10339 predates the vendoring support in the Go tool; it is about choosing "github.com/a/b/vendor/github.com/c/d" over "github.com/c/d". I would say that #10339 as written is obviated by GO15VENDOREXPERIMENT and this issue.

Once CL 17728 is merged both this issue and #10339 should probably be closed.

[zellyn]

I think this is fixed by https://go-review.googlesource.com/#/c/17728/

[cezarsa]

Regarding this issue I think I found another code path that wasn't considering packages inside /vendor and created a new CL fixing it: https://go-review.googlesource.com/#/c/22020/

The problem happens when the vendored package name is different from the base import path. goimports calls build.Import() to figure out the real package name, however, it was being called with an empty srcDir parameter this way it couldn't find packages inside /vendor.

[favadi]

@cezarsa what else need to be done to have your patch merged?

[ricardoseriani]

Please, any news on this ?

[FiloSottile]

Looks to me it was fixed by the mentioned CL, which was merged.