Thanks for the issue.

My general feeling on this is that this only matters for unimported completion, for packages with matching members, where the wrong package is scored higher. This should be a very rare occurrence, the benefit is marginal, and such additional configuration has a real cost in both maintenance and configuration complexity. So I don't see this as obviously worthwhile.

I wonder if instead we could improve the import path scoring in this case. Can you tell me more about the context? Are you in GOPATH or module mode? Have you imported either of those packages elsewhere in your project? Are either of those modules in your go.mod file?

CC @heschi

In this particular case it looks like both v.6-core and v2.1 are in the same module, so we don't have any module-level signal to use. This is related to #36077, in that sibling files could probably provide some hints.

• I'm in module mode.
• These packages are contained by the module github.com/go-gl/gl.
• I have imported v4.6-core in other packages within the same module.
• In some cases, gopls autocompletes v2.1 when I have imported v4.6-core in other packages in the same module.

such additional configuration has a real cost in both maintenance and configuration complexity. So I don't see this as obviously worthwhile.

I understand. However, I have already wasted hours on this (it causes very strange bugs), so it is certainly in my interests to find some solution that doesn't waste more time. I thought about creating a custom vetter to run with go vet -vettool=..., but based on microsoft/vscode-go#3219 it appears that adding -vettool=... to the vet flags for gopls would disable all the normal vetters, which is definitely not something I want.

@ramya-rao-a suggested using go.alternateTools to replace one of the standard tools with a custom shell script. Another thought I had was to run go get -vettool=... as a VSCode task - but from microsoft/vscode#2159 I conclude that I would need to use filesystem watching to detect changes. Both of these involve maintaining custom tooling which is IMO an ugly solution and one I want to avoid.

If gopls had some way to run additional commands when a file was saved, I could use that to run a custom vetter.

This is related to #36077, in that sibling files could probably provide some hints.

Are you saying that I could provide some hints? I'd love to be have some way to tell gopls which version I really want.

Or are you saying the authors of github.com/go-gl/gl could provide hints? That would be nice, but I need a solution that doesn't involve waiting for the maintainers of that project.

I work with the aws sdk a lot and often get the wrong imports for boilerplate code I write (copy-paste) over and over again. For example this code block always results in a wrong import for me:

	sess := session.New(&aws.Config{
		Region: aws.String("us-east-1"),
	})
	s3client := s3.New(sess)

Today this imported:

import (
	"github.com/aws/aws-sdk-go/aws"
	"github.com/aws/aws-sdk-go/service/s3"
	"github.com/softlayer/softlayer-go/session"
)

Where I wanted it to import:

	"github.com/aws/aws-sdk-go/aws/session"

Its extra frustrating because I've never used softlayer for anything but it always wins the imports battle (it is presumably in my mod cache because it is a dependency of some other thirdparty library I use somewhere).

If there was a configuration option for specifying preferred imports I would use it for this.

Sorry this is frustrating. Perhaps this isn't as rare as I originally thought, because of the limited logic of unimported completion.

@firelizzard18

Are you saying that I could provide some hints? I'd love to be have some way to tell gopls which version I really want.

I think what @heschi is saying is that if unimported completion used the same logic as organize imports, it would take into account which import is used in sibling files (and therefore would be smarter).

@psanford

Its extra frustrating because I've never used softlayer for anything but it always wins the imports battle

From your description, I think this also might be solved by taking sibling imports into account.

if unimported completion used the same logic as organize imports, it would take into account which import is used in sibling files (and therefore would be smarter).

If gopls checked the other files in my module and 'said', "Package gl has been resolved as .../v4.6-core/gl elsewhere in this module, so we'll use that version now," that would solve my problem.

Thanks.

Closing this as a duplicate of #36077, which is prioritized for gopls/v1.0.0.