-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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/imports: prefer latest versions of modules #41800
Comments
@Fenny thanks for filing an issue. Please answer the following questions to narrow down the underlying issue.
|
Relevant discussion on Slack: https://gophers.slack.com/archives/CJZH85XCZ/p1601057566019700. /cc @heschik |
#36077 is not particularly related. This is a reasonable feature request but I don't think it's trivial, and I'm somewhat disinclined to work on it until the dust surrounding major versions settles. Once the right dependency is in go.mod (and any old ones are removed) the ranking should work okay. |
In any case, this is a |
Default settings ( fresh install )
Nope, just a blank file without a |
@heschik
I suspect that this issue is itself a large part of “the dust surrounding major versions”. (See #40323 (comment) and surrounding discussion.) |
If you and @jayconrod agree that a simple "greatest major version is best" heuristic is appropriate for the foreseeable future then I'd probably be more open to it. If there's going to be more work to do to account for retraction and stuff, then I would rather deal with it holistically. |
I think the current “whatever is already in use” heuristic is best when it applies, and if nothing is already in use then arbitrarily choosing the highest-version import path is strictly preferable to arbitrarily choosing some other version. There will probably always be further ways we could fine-tune the heuristic (such as: prefer an import path whose latest release is not deprecated, prefer an import path that has a non-retracted release version, and perhaps others). But I don't think we can figure out how important those fine-tunings are until we fix the properties that we already know are important, such as this one. |
Change https://golang.org/cl/261084 mentions this issue: |
This changes bumps relevance for modules with major versions >1 so the results for unimported members are ordered by major version. Updates golang/go#41800 Change-Id: I64f4a1cf78a101acf4229433d06b5793246962f5 Reviewed-on: https://go-review.googlesource.com/c/tools/+/261084 Run-TryBot: Danish Dua <danishdua@google.com> Trust: Danish Dua <danishdua@google.com> Reviewed-by: Heschi Kreinick <heschi@google.com>
Change https://go.dev/cl/582557 mentions this issue: |
I believe this has been fixed by https://go.dev/cl/641776. For instance, see Test58382 in golang.org/x/tools/gopls/test/integration/misc/imports_test.go |
Is your feature request related to a problem? Please describe.
It's nice to rely on the auto-import feature, but it seems to always default to an older version.
Describe the solution you'd like
It would be better to always prefer the latest version of a package
Describe alternatives you've considered
To manually add
v2
behind the import path ( gets boring after a while )Additional context
In this screenshot, you can see it defaults to
v1
even though I havev2
installedThe text was updated successfully, but these errors were encountered: