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: update editor instructions for go.work #50955

Open
findleyr opened this issue Feb 1, 2022 · 13 comments
Open

x/tools/gopls: update editor instructions for go.work #50955

findleyr opened this issue Feb 1, 2022 · 13 comments
Labels
Documentation gopls Tools
Milestone

Comments

@findleyr
Copy link
Contributor

@findleyr findleyr commented Feb 1, 2022

Some language-agnostic LSP clients need to be configured with root patterns (e.g. open the workspace to the folder containing go.mod).

We should update those to account for using go.work as the workspace root.

EDIT: the main things to look for are:

  1. LSP clients should choose the workspace root correctly. Ideally, they should set the workspace root to the first parent directory (or current directory) containing a go.work file (i.e. find nearest go.work file up the directory hierarchy). If no such directory exists, they should repeat with go.mod. Unfortunately, not all LSP clients support this multi-phase search, so an alternate heuristic is to take the farthest directory up the directory hierarchy that contains either a go.work file or go.mod file.
/A/go.work <- acceptable workspace folder
/A/B/go.mod <- avoid
/A/B/C/go.work  <- ideal workspace folder 
/A/B/C/D/go.mod <- avoid
/A/B/C/D/E <- opened directory
  1. If possible, LSP clients should activate gopls for go.work files and send the "go.work" language identifier. This is much less critical than (1) -- clients could also do this for go.mod files and AFAIK none of them do, except VS Code.
@findleyr findleyr added this to the gopls/v0.8.0 milestone Feb 1, 2022
@gopherbot gopherbot added Tools gopls labels Feb 1, 2022
@gopherbot
Copy link

@gopherbot gopherbot commented Feb 1, 2022

Change https://golang.org/cl/382242 mentions this issue: gopls: update coc.nvim documentation for using go.work

gopherbot pushed a commit to golang/tools that referenced this issue Feb 4, 2022
For golang/go#50955

Change-Id: Idab88d258ceab3312adccd97eb58ed64e5fb5053
Reviewed-on: https://go-review.googlesource.com/c/tools/+/382242
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
@findleyr
Copy link
Contributor Author

@findleyr findleyr commented Feb 4, 2022

gopls now supports go.work files at master. @muirdm or @bcmills, would you be able to update our emacs documentation at some point in the next few weeks? No worries if not -- I can figure it out -- but I know you have contributed to that documentation before.

See the edit in the top comment and the associated CL for coc.nvim for more information.

@findleyr
Copy link
Contributor Author

@findleyr findleyr commented Feb 4, 2022

@myitcv and @leitzler I believe govim should implement these heuristics for its users. Would you be able to verify its functionality with go.work files?

@findleyr
Copy link
Contributor Author

@findleyr findleyr commented Feb 4, 2022

@dr2chase do you know if sublime has heuristics for deriving the workspace folder? If so, could you help update the sublime documentation?

@dr2chase
Copy link
Contributor

@dr2chase dr2chase commented Feb 4, 2022

I have not yet learned about Go workspaces, so I am a bit in the dark here. Seems like I should look at this.

@bcmills
Copy link
Member

@bcmills bcmills commented Feb 4, 2022

I haven't updated my own .emacs for workspace mode yet, but when I do I'll send a CL.

(I suspect that it will involve another parallel implementation of the project hook, but I expect to need a little bit of work to get it to prioritize the go.work project root over the go.mod one when both are present.)

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 1, 2022

Change https://go.dev/cl/388576 mentions this issue: gopls: update neovim documentation for using go.work

gopherbot pushed a commit to golang/tools that referenced this issue Mar 1, 2022
For golang/go#50955

Change-Id: I8882239868d060a444466a466d30c3de9aaa31ef
GitHub-Last-Rev: 6395f14
GitHub-Pull-Request: #370
Reviewed-on: https://go-review.googlesource.com/c/tools/+/388576
Trust: Nooras Saba‎ <saba@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
@dr2chase
Copy link
Contributor

@dr2chase dr2chase commented Mar 1, 2022

Follow-up -- for the case of the Go source tree, with go.work =

go 1.18

use (
	.
	cmd
)

and Sublime/LSP tweaked to use gopls@latest (and the sublime editor instructions for gopls include that) it all seems to "just work". Is that what we want, or were we looking for something more?

@findleyr
Copy link
Contributor Author

@findleyr findleyr commented Mar 1, 2022

@dr2chase "Just works" is good enough for me! Thanks for trying it out.

@findleyr
Copy link
Contributor Author

@findleyr findleyr commented Mar 3, 2022

Some (but not all) editor instructions have been updated. Moving this to the next milestone.

@findleyr findleyr removed this from the gopls/v0.8.0 milestone Mar 3, 2022
@findleyr findleyr added this to the gopls/v0.8.1 milestone Mar 3, 2022
@findleyr findleyr removed this from the gopls/v0.8.1 milestone Mar 14, 2022
@findleyr findleyr added this to the gopls/v0.8.2 milestone Mar 14, 2022
leitzler added a commit to govim/govim that referenced this issue Mar 20, 2022
As per golang/go#50955 govim now uses the directory of GOWORK if set
before falling back to use the directory of GOMOD.

The added test also introduced a new testscript test feature, setting
which directory vim should start from.
leitzler added a commit to govim/govim that referenced this issue Mar 20, 2022
As per golang/go#50955 govim now uses the directory of GOWORK if set
before falling back to use the directory of GOMOD.

The added test also introduced a new testscript test feature, setting
which directory vim should start from.
leitzler added a commit to govim/govim that referenced this issue Mar 22, 2022
As per golang/go#50955 govim now uses the directory of GOWORK if set
before falling back to use the directory of GOMOD.

The added test also introduced a new testscript test feature, setting
which directory vim should start from.
@findleyr findleyr removed this from the gopls/v0.8.2 milestone Mar 31, 2022
@findleyr findleyr added this to the gopls/v0.8.3 milestone Mar 31, 2022
@findleyr findleyr removed this from the gopls/v0.8.3 milestone Apr 5, 2022
@findleyr findleyr added this to the gopls/v0.8.4 milestone Apr 5, 2022
@jguenther
Copy link

@jguenther jguenther commented Apr 8, 2022

FWIW, using emacs+gopls with projectile and lsp-mode this Just Worked™️ for me after cleaning up my lsp-mode workspace folders with lsp-workspace-folders-remove so that the only entry in my workspace folders was the $BASE dir containing the root module and the new go.work file (details below)

(prior to this, I was using vendored deps so I couldn't use the experimentalWorkspaceModule feature (#50214))


Project structure

  • project checked out in $BASE, with the "root module" meaning $BASE/go.mod

  • projectile project root is $BASE, detected by the .git dir there

  • technically I told projectile to treat go.work files as project root files, but I've never tried using a go.work that wasn't already in a project root due to the presence of a .git dir, so I don't think this had any effect. But YMMV:

    (add-to-list 'projectile-project-root-files "go.work")

Modules

# previously each of these module dirs were added to my workspace folders (lsp-workspace-folders-add)
go.mod
path/to/other/module/go.mod
another/one/go.mod

Setting up workspaces with go work

  1. upgrade go to 1.18
  2. reinstall gopls using go 1.18
  3. cd $BASE
  4. go work init
  5. go work use ./path/to/other/module ./another/one .

Setting up lsp-mode to use workspaces

  1. lsp-workspace-folders-remove, select $BASE/path/to/other/module
  2. lsp-workspace-folders-remove, select $BASE/another/one

Now, the only dir in lsp-mode workspace folders for this project is $BASE.

Restart gopls

  1. lsp-workspace-restart

At this point everything Just Worked™️. I can navigate refs between these modules, jump to definition goes to the file in the source module instead of the file vendored in my vendor dir, etc.

NOTE I'm not sure if eglot or the builtin project.el package would require any other setup as I don't use them.


cc @findleyr @bcmills

@findleyr
Copy link
Contributor Author

@findleyr findleyr commented May 3, 2022

@jguenther thanks for that, we can include this in our editor instructions. Do you know if using projectile is strictly required for this to work?

CC @adonovan (another eglot user)

@findleyr findleyr removed this from the gopls/v0.8.4 milestone May 9, 2022
@findleyr findleyr added this to the gopls/on-deck milestone May 9, 2022
@findleyr
Copy link
Contributor Author

@findleyr findleyr commented May 18, 2022

Keeping this open to track additional documentation for other editors, but it is a lower priority now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation gopls Tools
Projects
None yet
Development

No branches or pull requests

6 participants