Closed
Description
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"
.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
findleyr commentedon Jun 9, 2021
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 commentedon Jun 9, 2021
In this particular case it looks like both
v.6-core
andv2.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 commentedon Jun 9, 2021
github.com/go-gl/gl
.v4.6-core
in other packages within the same module.v2.1
when I have importedv4.6-core
in other packages in the same module.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 rungo 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.
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 commentedon Jun 10, 2021
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:
Today this imported:
Where I wanted it to import:
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 commentedon Jun 10, 2021
Sorry this is frustrating. Perhaps this isn't as rare as I originally thought, because of the limited logic of unimported completion.
@firelizzard18
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
From your description, I think this also might be solved by taking sibling imports into account.
firelizzard18 commentedon Jun 11, 2021
If
gopls
checked the other files in my module and 'said', "Packagegl
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 commentedon Jun 11, 2021
Thanks.
Closing this as a duplicate of #36077, which is prioritized for gopls/v1.0.0.
4 remaining items