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: prefer golang.org/x/net/context #15471

Open
broady opened this issue Apr 27, 2016 · 6 comments

Comments

@broady
Copy link
Member

commented Apr 27, 2016

While people are still writing packages that need to be compatible with pre-Go 1.7 code, goimports should import golang.org/x/net/context instead of the new std context package.

@broady broady changed the title tools: cmd/goimports should prefer golang.org/x/net/context x/tools/cmd/goimports: prefer golang.org/x/net/context Apr 27, 2016

@bradfitz bradfitz added this to the Unreleased milestone May 4, 2016

@bradfitz

This comment has been minimized.

Copy link
Member

commented May 4, 2016

Maybe?

Or maybe only if you're outside of the standard library? :)

@RaduBerinde

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2016

I think a more general solution would be useful - I hit this all the time, but not only with context. E.g. my project has a log package but sometimes goimports chooses some other log.

I propose allowing the user to specify (preferably via a config file, but command line would also work) preferences for mapping package names to import path. For packages that show up there, those import paths are preferred.

@RaduBerinde

This comment has been minimized.

Copy link
Contributor

commented Sep 30, 2016

To follow up to the previous comment, I found out there is already support for a .goimportsignore file that can be put in $GOPATH/src. I wonder if adding context to that file would work for this situation.

Edit: never mind, I tried it and adding context doesn't work (I guess it doesn't work for built-in packages).

@bradfitz

This comment has been minimized.

Copy link
Member

commented Oct 1, 2016

The ignore file is about paths on disk to ignore, not packages to ignore.

What should happen here is we should recommend symbols from Go 1.N when the user's GOROOT is Go 1.N-1.

@flimzy

This comment has been minimized.

Copy link

commented May 2, 2017

What should happen here is we should recommend symbols from Go 1.N when the user's GOROOT is Go 1.N-1.

I don't think it's (specifically) about Go versions. As @RaduBerinde pointed out, and as I often experience, it's also about importing the "wrong" version of many libraries (log is a common example, experienced by both me and @RaduBerinde--but it's not the only one).

What I would like is the option to give goimports hints as to which package to prefer. This might be expressed by a simple ordered list:

log: github.com/mycustom/log, github.com/someother/log, log

goimports would then use the first one to match its detected signature.

Ideally, this could also be configured on a per-package/workspace basis (i.e. a github.com/my/package/.goimportsignore), but that's probably not related specifically to this issue.

@btracey

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2017

A related issue to this is preferring golang.org/x/exp/rand over math/rand. It would be nice if .goimportsignore could be modified to prefer one over the other.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.