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: always choose internal copy over outer copy #10339

Closed
rsc opened this issue Apr 3, 2015 · 6 comments
Closed

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

rsc opened this issue Apr 3, 2015 · 6 comments
Milestone

Comments

@rsc
Copy link
Contributor

@rsc rsc commented Apr 3, 2015

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.

@rsc rsc added this to the Go1.5 milestone Apr 3, 2015
@thockin
Copy link

@thockin thockin commented Apr 3, 2015

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.

@josharian josharian added the repo-tools label Apr 3, 2015
@rsc rsc changed the title goimports: always choose internal copy over outer copy x/tools/cmd/goimports: always choose internal copy over outer copy Apr 14, 2015
@rsc rsc modified the milestones: Unreleased, Go1.5 Apr 14, 2015
@rsc rsc removed the repo-tools label Apr 14, 2015
@mdwhatcott
Copy link

@mdwhatcott mdwhatcott commented Feb 1, 2016

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

@rsc
Copy link
Contributor Author

@rsc rsc commented Feb 1, 2016

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

@bradfitz bradfitz removed their assignment Feb 1, 2016
@mdwhatcott
Copy link

@mdwhatcott mdwhatcott commented Feb 1, 2016

Understood

@zellyn
Copy link

@zellyn zellyn commented Mar 2, 2016

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Jul 21, 2016

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)

@bradfitz bradfitz closed this Jul 21, 2016
@golang golang locked and limited conversation to collaborators Jul 21, 2017
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
7 participants
You can’t perform that action at this time.