Maybe?

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

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.

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

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.

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.

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.

While there was some discussion of related features, 1.7 was a long time ago, so the core request is obsolete. Please file a new issue if you're still interested in the related features.