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: defining the workspace root #36899

Open
stamblerre opened this issue Jan 30, 2020 · 2 comments
Open

x/tools/gopls: defining the workspace root #36899

stamblerre opened this issue Jan 30, 2020 · 2 comments
Labels
Milestone

Comments

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Jan 30, 2020

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

  • Open workspace at the module root (directory containing the go.mod file). The scope is the entire module.
  • Open a subdirectory of a module. The scope is the subdirectory that has been opened.

Unsupported

  • Open a directory that contains a module in a subdirectory. gopls will not work in this case.

GOPATH mode

Supported

  • Open a directory inside of your GOPATH. The scope is the open directory.

At your own risk

  • Open your entire GOPATH. The workspace scope will be your entire GOPATH. Note that this will cause gopls to load your entire GOPATH. If your GOPATH is large, this will take a long time and cause gopls 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

  • Open a directory containing your GOPATH. Similar to the case above, this will cause 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 once gopls reaches v1.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 of gopls 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 reaches v1.0.0.

If you have additional use cases that are not mentioned above, please comment below.

@stamblerre stamblerre added this to the gopls/v1.0.0 milestone Jan 30, 2020
@myitcv

This comment has been minimized.

Copy link
Member

@myitcv myitcv commented Jan 30, 2020

Thanks for documenting this @stamblerre.

In module mode, specifically:

Open a subdirectory of a module

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 cmd/go in a sub directory still has a module context of the main module itself. Reason being: we're talking in terms of modules here (given we're in module mode) and not packages.

@stamblerre

This comment has been minimized.

Copy link
Contributor Author

@stamblerre stamblerre commented Jan 30, 2020

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.