Skip to content

x/tools/gopls: add a mechanism to control what packages are preferred #46660

Closed
@firelizzard18

Description

@firelizzard18

I want a way to tell gopls, "Whenever I trigger the auto-importer for package gl, I specifically want github.com/go-gl/gl/v4.6-core/gl." Something like:

{
    "gopls": {
        "importPreference": {
            "gl": "github.com/go-gl/gl/v4.6-core/gl"
        }
    }
}

What version of gopls are you using (gopls version)?

$ ~/go/bin/gopls version
golang.org/x/tools/gopls v0.6.11
    golang.org/x/tools/gopls@v0.6.11 h1:7S2k0xuVYc3secjy2uz0n+fGYxGJU6gXsLOmQ/r1HoI=

I am using Visual Studio Code and vscode-go.

What did you do?

In a file in a package in which I have not yet imported a gl package, I typed gl.stdr and selected gl.STATIC_DRAW from the dropdown.

What did you expect to see?

I want to use import "github.com/go-gl/gl/v4.6-core/gl".

What did you see instead?

gopls added import "github.com/go-gl/gl/v2.1/gl".

Activity

added
ToolsThis label describes issues relating to any tools in the x/tools repository.
goplsIssues related to the Go language server, gopls.
on Jun 9, 2021
added this to the Unreleased milestone on Jun 9, 2021
added
FeatureRequestIssues asking for a new feature that does not need a proposal.
on Jun 9, 2021
findleyr

findleyr commented on Jun 9, 2021

@findleyr
Member

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

heschi

heschi commented on Jun 9, 2021

@heschi
Contributor

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.

firelizzard18

firelizzard18 commented on Jun 9, 2021

@firelizzard18
ContributorAuthor
  • 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.

psanford

psanford commented on Jun 10, 2021

@psanford

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.

findleyr

findleyr commented on Jun 10, 2021

@findleyr
Member

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.

firelizzard18

firelizzard18 commented on Jun 11, 2021

@firelizzard18
ContributorAuthor

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.

findleyr

findleyr commented on Jun 11, 2021

@findleyr
Member

Thanks.

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

4 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    FeatureRequestIssues asking for a new feature that does not need a proposal.FrozenDueToAgeToolsThis label describes issues relating to any tools in the x/tools repository.goplsIssues related to the Go language server, gopls.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @psanford@firelizzard18@stamblerre@gopherbot@heschi

        Issue actions

          x/tools/gopls: add a mechanism to control what packages are preferred · Issue #46660 · golang/go