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/imports: prefer latest versions of modules #41800

Open
Fenny opened this issue Oct 5, 2020 · 9 comments
Open

x/tools/cmd/imports: prefer latest versions of modules #41800

Fenny opened this issue Oct 5, 2020 · 9 comments

Comments

@Fenny
Copy link

@Fenny Fenny commented Oct 5, 2020

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 have v2 installed

@hyangah
Copy link
Contributor

@hyangah hyangah commented Oct 5, 2020

@Fenny thanks for filing an issue. Please answer the following questions to narrow down the underlying issue.

  • what's your vscode setting like (any "go", "[go]" prefixed attributes) ?
  • are you already using v2 somewhere else (in other packages in the project, or in go.mod, or used in other projects)?
@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Oct 5, 2020

Relevant discussion on Slack: https://gophers.slack.com/archives/CJZH85XCZ/p1601057566019700.
There is also a related issue: #36077.

/cc @heschik

@heschik
Copy link
Contributor

@heschik heschik commented Oct 5, 2020

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

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Oct 5, 2020

In any case, this is a goimports-specific issue so let's transfer it to the golang/go issue tracker.

@stamblerre stamblerre transferred this issue from golang/vscode-go Oct 5, 2020
@stamblerre stamblerre changed the title Auto import does not choose latest version x/tools/cmd/imports: prefer latest versions of modules Oct 5, 2020
@gopherbot gopherbot added the Tools label Oct 5, 2020
@gopherbot gopherbot added this to the Unreleased milestone Oct 5, 2020
@Fenny
Copy link
Author

@Fenny Fenny commented Oct 5, 2020

@Fenny thanks for filing an issue. Please answer the following questions to narrow down the underlying issue.

  • what's your vscode setting like (any "go", "[go]" prefixed attributes) ?

Default settings ( fresh install )

  • are you already using v2 somewhere else (in other packages in the project, or in go.mod, or used in other projects)?

Nope, just a blank file without a go.mod, but even if I go mod init <project> it results in the same behavior

@bcmills
Copy link
Member

@bcmills bcmills commented Oct 6, 2020

@heschik

I'm somewhat disinclined to work on it until the dust surrounding major versions settles.

I suspect that this issue is itself a large part of “the dust surrounding major versions”. (See #40323 (comment) and surrounding discussion.)

@heschik
Copy link
Contributor

@heschik heschik commented Oct 6, 2020

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.

@bcmills
Copy link
Member

@bcmills bcmills commented Oct 6, 2020

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.

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 13, 2020

Change https://golang.org/cl/261084 mentions this issue: internal/imports: bump relevance for modules with higher major versions

gopherbot pushed a commit to golang/tools that referenced this issue Oct 13, 2020
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants