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/gopls: removing dependencies with go get path@none adds all indirect dependencies #43335

Closed
stamblerre opened this issue Dec 23, 2020 · 6 comments
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@stamblerre
Copy link
Contributor

We are currently using go get <module path>@none to remove unused dependencies. However, this command also adds all of the given <module path>'s dependencies as indirect dependencies to the current module.

@bcmills, @jayconrod, @matloob: Is there a way to avoid this?

/cc @heschik @findleyr

@stamblerre stamblerre added this to the gopls/v0.6.2 milestone Dec 23, 2020
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Dec 23, 2020
@bcmills
Copy link
Contributor

bcmills commented Dec 23, 2020

I'm planning to revise this behavior for lazy modules (as part of #36460), but I don't know of any way to avoid it in today's eager modules.

Would it make sense for gopls to remove unused dependencies using go mod edit -droprequire instead? But I guess that risks downgrading modules that actually are used.

@bcmills
Copy link
Contributor

bcmills commented Dec 23, 2020

I guess my real answer is, “lazy loading will solve this, hopefully in 1.17”. 😞

@stamblerre
Copy link
Contributor Author

Ah, I see--thanks for the quick response! The reason we were using the go command to do this was because we wanted to keep the go.sum file tidy, but maybe we can just do textual edits for removing a dependency until 1.17.

@bcmills
Copy link
Contributor

bcmills commented Dec 23, 2020

So, you could check whether the go.mod and go.sum are tidy before the edit, and if they are, run go get <path>@none followed by go mod tidy. That should DTRT most of the time, albeit at the cost of running go mod tidy in the diagnostic.

@stamblerre
Copy link
Contributor Author

That should DTRT most of the time, albeit at the cost of running go mod tidy in the diagnostic.

Yeah, we can actually avoid calling it in the diagnostic and only do it when the fix is selected, so that should actually be fine. I didn't love the idea of 2 code paths for the same fix type, but maybe that is the best approach for now.

@gopherbot
Copy link

Change https://golang.org/cl/279716 mentions this issue: internal/lsp: remove dependencies using text edits when necessary

@stamblerre stamblerre added this to Needs Triage in vscode-go: gopls by default via automation Dec 23, 2020
@stamblerre stamblerre moved this from Needs Triage to Critical in vscode-go: gopls by default Dec 23, 2020
@stamblerre stamblerre moved this from Critical to In progress in vscode-go: gopls by default Dec 23, 2020
vscode-go: gopls by default automation moved this from In progress to Done Dec 24, 2020
@golang golang locked and limited conversation to collaborators Dec 24, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
No open projects
Development

No branches or pull requests

3 participants