Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/cmd/goimports: prioritize closer package #17557

Closed
henryas opened this issue Oct 23, 2016 · 11 comments
Closed

x/tools/cmd/goimports: prioritize closer package #17557

henryas opened this issue Oct 23, 2016 · 11 comments

Comments

@henryas
Copy link

@henryas henryas commented Oct 23, 2016

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.

@bradfitz bradfitz changed the title Proposal: (goimports) Prioritize closer package when importing packages with the same names. x/tools/cmd/goimports: prioritize closer package Oct 23, 2016
@bradfitz bradfitz added this to the Unreleased milestone Oct 23, 2016
@alexcarol
Copy link
Contributor

@alexcarol alexcarol commented Oct 24, 2016

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
Copy link
Contributor

@bradfitz bradfitz commented Oct 24, 2016

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
Copy link
Contributor

@alexcarol alexcarol commented Oct 25, 2016

Thanks, I'll get to it :)

@aravindc26
Copy link

@aravindc26 aravindc26 commented Dec 17, 2016

@alexcarol what is the status of this issue ?

@alexcarol
Copy link
Contributor

@alexcarol alexcarol commented Dec 18, 2016

@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
Copy link

@gavrie gavrie commented Dec 18, 2016

@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
Copy link

@aravindc26 aravindc26 commented Dec 18, 2016

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

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 15, 2017

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

jtwatson pushed a commit to jtwatson/tools that referenced this issue Feb 16, 2017
1. Prefer imports from within the same package
2. Prefer imports that are closer to the current package

fixes golang/go#17557

Change-Id: Iec55a294d396feac6234be307e08608b8559f65c
jtwatson pushed a commit to jtwatson/tools that referenced this issue Feb 16, 2017
1. Prefer imports from within the same package with validation
2. Prefer imports that are closer to the current package

fixes golang/go#17557

Change-Id: Iec55a294d396feac6234be307e08608b8559f65c
@kaedys
Copy link

@kaedys kaedys commented May 30, 2017

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
Copy link

@gopherbot gopherbot commented Jul 8, 2017

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

@matthewmueller
Copy link

@matthewmueller matthewmueller commented Nov 19, 2017

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!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.