Go: x/tools/cmd/goimports: prioritize closer package

[henryas]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

Go version 1.7.3

What operating system and processor architecture are you using (go env)?

Windows 10 Home 64-bit, with Sublime Text IDE (with GoSublime)

What did you do?

Had different projects, each containing a package with the same name, and then in one of the projects, created a go file that used of one of the packages and called goimports to suggest an import line.

What did you expect to see?

I was hoping to see goimports suggesting an import line that is closer to the current file. In this case, it should suggest the package in the current project.

Or if there are multiple packages with the same name within the same project, it should suggest an import line that is closer to the current file.

What did you see instead?

Goimports currently suggests a random import line for packages with the same name, which is often inaccurate at times. It often suggests a same-name package from different projects, which is irrelevant.

If goimports can understand which import line is closer, it will appear to better understand the context of the package being imported and act more intelligently.

[alexcarol]

I'd be happy to take this one on. To be clear, std lib imports should still have priority over others, am I right? @bradfitz

[bradfitz]

To be clear, std lib imports should still have priority over others, am I right?

Not necessarily.

If there are two files in a package, and you're editing foo.go and adding the line io.Copy (and the no io package is already imported), but bar.go in the same package already imports io as:

   import io "github.com/altstdlib/io"

... then you'd probably want to do the same thing as the other file in the same package. goimports already scans that and knows that info. I think there's a TODO yet, but it has the info.

But otherwise, if it's not already being used, then stdlib should win, instead of closest.

[alexcarol]

Thanks, I'll get to it :)

[aravindc26]

@alexcarol what is the status of this issue ?

[alexcarol]

@aravindc26 i haven't been able to get around the issue, I might work on it at some point, but if you want to work on the issue yourself you're welcome to do so, sorry for the inconvenience :/

[gavrie]

@aravindc26: Were you planning to work on this, or are you just interested in the outcome?
I was thinking of taking this on, but only if you're not on it already.

@alexcarol

[aravindc26]

@alexcarol @gavrie let me work on this issue :)

[gopherbot]

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

[kaedys]

Has there been any traction on this issue? It's irritating the living daylights out of me. We have a trio of projects that share similar structures, and thus have identically named packages in a number of places. Goimports happily imports the out-of-project versions instead of the local versions ~90% of the time.

[gopherbot]

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

[matthewmueller]

Works like magic! For anyone wanting to use this now, you can upgrade your goimports now by doing the following:

go get -u -v golang.org/x/tools/imports
go install golang.org/x/tools/cmd/goimports/...

Thanks for resolving this one!