search

microsoft / vscode-go

An extension for VS Code which provides support for the Go language. We have moved to https://github.com/golang/vscode-go
Other
5.93k stars 648 forks source link

Add package to workspace in module mode #3195

Closed sky126 closed 4 years ago

sky126 commented 4 years ago

When use go.mod and execute command Go: Add package to workspace display Could not find package github.com/gin-gonic/gin

hyangah commented 4 years ago

@sky126 In modules mode, the command adds the package loaded in the module cache to the workspace. The error may indicate the module cache is not yet populated. Can you try to build the project from the integrated terminal (so the go command downloads the dependencies)? Or, if you are using the language server, I guess the language server should do some cache population job behind while doing code analysis.

@ramya-rao-a @stamblerre What is the purpose/intention of Go: Add package to workspace in modules mode? In my testing, the workspace loads the path to the module cache. As you know, codes in the module cache are not supposed to be modified. Shouldn't this functionality be rethought in modules mode?

stamblerre commented 4 years ago

I agree that this feature doesn't make much sense in module mode. Maybe it could only work for replace targets?

sky126 commented 4 years ago

But official package is no problem. This feature is convenient for reading the source code.

ramya-rao-a commented 4 years ago

What is the purpose/intention of Go: Add package to workspace in modules mode? In my testing, the workspace loads the path to the module cache. As you know, codes in the module cache are not supposed to be modified. Shouldn't this functionality be rethought in modules mode?

The purpose was to load different packages in a multi root workspace mode in VS Code.

Right now, you can even add standard packages to the workspace. I would assume that standard packages should not be modified either right? So, why restrict the packages from being added to the workspace?

hyangah commented 4 years ago

@sky126 As I described in my previous explanation that is because the package (and its module) is not yet loaded in the cache. Run go get <the package> or if your project already has dependency on the package declared, try to build (so the go command can download the module in the cache). If the module/package is in the cache, you will be able to add that to the workspace. If not, let us know.

Standard packages can be loaded because they are already available with the go command.

@ramya-rao-a Depending on where the standard package is located, it can be modified and even go build causes the standard library to be rebuilt in many cases.

Depending on the intention, we should do more in the modules mode.

If the main purpose is just to ease the navigation of the dependencies, loading the readonly source code in the module cache is fine (and it already works). A couple of improvement to explore in this case:

1) if the module cache is not populated, maybe download the module. If the package is not yet specified in go.mod, downloading the module will update go.mod. We need to decide whether that is desirable or not. 2) if we keep allowing to add the readonly source code in the workspace, maybe it would be desirable to make it more clear that that is read-only. Is there any vscode feature that makes it clear and disallow edits? Does gopls already recognize readonly source code and ignores the unsaved modification in buffer? 3) what should we do if the user upgrades the dependency? (e.g. by clicking the codelens of go.mod)

If the main purpose is to allow users to edit the dependency source code (for debugging, etc), maybe we can think about other improvements like applying what gohack does - downloading the dependencies in a different, writable directory and make the project to use the downloaded source code by adding replace in go.mod.

sky126 commented 4 years ago

suggest fix depend packages available. main purpose is edit the dependency source code for debugging or reading source code.

ramya-rao-a commented 4 years ago

If the main purpose is just to ease the navigation of the dependencies, loading the readonly source code in the module cache is fine (and it already works).

if the module cache is not populated, maybe download the module. If the package is not yet specified in go.mod, downloading the module will update go.mod. We need to decide whether that is desirable or not.

I would prefer to not get into the business of downloading packages automatically. In the module cache does not have the code, then I'd rather throw an error that the module is not available. User can choose to download it if needed. At most, the error/warning can have a button that can download the package using the existing Go: Get Package command

if we keep allowing to add the readonly source code in the workspace, maybe it would be desirable to make it more clear that that is read-only. Is there any vscode feature that makes it clear and disallow edits? Does gopls already recognize readonly source code and ignores the unsaved modification in buffer?

Currently we show a warning if one edits a file that starts with // Code generated .* DO NOT EDIT. But there is no feature out of the box that will stop one from editing files as far as I know.

If gopls can identify such files, then it can throw such warnings as well

stamblerre commented 4 years ago

If gopls can identify such files, then it can throw such warnings as well

gopls does do this already.

I filed https://github.com/golang/vscode-go/issues/170 upstream to continue the work on this. We can think of some alternatives for how this feature would work in module mode, along the lines that @hyangah suggested.