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

Jump to bottom

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
Labels
FrozenDueToAge
Milestone
Unreleased

Comments

@rsc
Copy link
Contributor

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 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.

@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

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

@rsc
Copy link
Contributor Author

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

Understood

@pwaller pwaller mentioned this issue Feb 8, 2016
Closed
@zellyn
Copy link

zellyn commented Mar 2, 2016

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

@bradfitz
Copy link
Contributor

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)

@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.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
7 participants
@bradfitz @zellyn @josharian @rsc @mdwhatcott @thockin @gopherbot