x/tools/gopls: defining the workspace root #36899
Comments
Thanks for documenting this @stamblerre. In module mode, specifically:
Can you expand on the motivation behind limiting the scope to the subdirectory tree? My intuition was that the scope would have been the entire module, just as running |
@myitcv: We are still considering the path forward here. For now, this is the current state, but it's possible that we may change it to be module-scoped in the future. |
Would you consider an implementation in $GOPATH mode that allows one to set the scope when opening gopls - perhaps as a configuration or startup flag option? I frequently jump to a given code location before opening my editor; it's inconvenient to need to open my $GOPATH root (or a sufficiently "high" parent directory) in order to find all the references. For example, I have a $GOPATH of Any time I'm within |
@joeblubaugh: Yes, that is our eventual goal for GOPATH mode - I think a scope configuration is probably what we'll go with. I'll post more information here once we have more details planned out. |
I'm sorry, it's not totally clear from the write-up.
Is this a design limitation, or just not currently implemented? Using VS Code (and having spent an afternoon suffering from golang/vscode-go#250 (comment)) it'd be good to understand if this is a temporary limitation, or if I will need to permanently change workflows. golang/vscode-go#226 (comment) is what brought me here. Or perhaps I'm misunderstanding, or this is really a feature vscode-go should implement, not gopls. Perhaps vscode-go it should be starting gopls in the correct directory for my currently-open file/package, so gopls sees the supported case of "go.mod in |
This is something we are working on improving for future versions of |
One use case we haven't considered yet is directories that contain multiple Go files, each for a different command. Right now, |
Keeping this issue open to ensure that its content eventually gets converted to documentation. |
For vscode I have a workaround, do not know if this work for other editors. My directory structure is:
opening "Somepoject1" in vscode causes a problem.
If i start working on a project I open the respective directory in "Workspace"s in vscode. There I add al the microservice directories from the corresponding project directory in "Projects" to the workspace. it's a little bit of work to setup but it works. no errors any more |
goland support this feature. vscode how config? @stamblerre , work fine. thanks! {
"gopls": {
"buildFlags": ["-tags=wireinject"],
"experimentalWorkspaceModule": true
},
} |
You can use VS Code's File -> Add Folder to Workspace to add multiple modules to your project. |
…dem across different environments golang/go#36899 , similar error
I use vscode remote ssh remote workspace path: /home/wenzhenglin/gocode/src/example.com.com/naas go.mod: This issue if it's relate, that makes vscode almost non-functional, only to disable the format, almlost every time I save a file (it just waiting long time and still fail to format, a few time works though) I'm using Kubernetes's apiserver-builder-alpha to generate codes, it forced to create project under GOPATH. that's bad, I can't easily to change the project path to outside GOPATH. // updated my test case // updated link |
@chinglinwen: It's fine to keep your project in your |
@stamblerre yep, issue #236 is more alike for my case. Sorry that vscode just confused me, and I don't know what's the real problem.
I don't open src folder, but open src/example.com/naas, the folder under it, so I don't know why you think so. One of problem is that it sometimes works and sometimes not, I don't have correct clue what's causing the problem. ( the log doesn't say much for me to get the clue ) . |
Did any of the suggestions on golang/vscode-go#236 help with the problem? |
Change https://golang.org/cl/283513 mentions this issue: |
@stamblerre The problem is I can't easy re-produce and verify, so it sometimes works okay, sometimes not.
However I try with extreme case that full of undefined names ( and no such import etc), in that way, it will show the saving box ( about 10 seconds I guess ), and got three times vscode disconnect(auto reconnect though). case:
try save and close etc version
vscode setting here if relate |
I'm seeing the following error messages in your logs:
This may indicate an issue. In any case, it will be easier to investigate on a dedicated issue, and it sounds like there may be some issues with VS Code here too. Do you mind filing a new issue with this information here? |
gopls
supports both module and GOPATH modes. However, we need to define a scope in which language features like references, rename, and implementation should operate. The following is subject to, and will likely, change.For now, we have the following cases:
Module mode
Supported
go.mod
file). The scope is the entire module.Unsupported
gopls
will not work in this case.GOPATH mode
Supported
At your own risk
GOPATH
. Note that this will causegopls
to load your entire GOPATH. If your GOPATH is large, this will take a long time and causegopls
to be very slow.To work around this case, you can create a new GOPATH that contains only the packages you want to work on.
Unsupported
gopls
to treat your entire GOPATH as the workspace scope. It will be very slow to start because it will try to find all of the Go files in the directory you have opened. It will then load all of the files it has found.We are working on addressing all of these cases and improving the behavior of
gopls
in the unsupported cases. All of these cases will be supported oncegopls
reachesv1.0.0
.We understand it may be inconvenient to change your typical workflow to accommodate frequent changes in
gopls
. In this case, it may be easier to stick with a version ofgopls
that works for you (gopls/v0.2.2
, for instance), or if you are using GOPATH,gopls
may not be the best tool to use until it reachesv1.0.0
.If you have additional use cases that are not mentioned above, please comment below.
The text was updated successfully, but these errors were encountered: