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: remove the experimentalWorkspaceModule setting #55331

Closed
findleyr opened this issue Sep 22, 2022 · 14 comments
Closed

x/tools/gopls: remove the experimentalWorkspaceModule setting #55331

findleyr opened this issue Sep 22, 2022 · 14 comments
Assignees
Labels
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

@findleyr
Copy link
Contributor

A follow-up to #52897, this issue tracks removal of the "experimentalWorkspaceModule" gopls setting.

@findleyr findleyr added this to the gopls/v0.11.0 milestone Sep 22, 2022
@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 Sep 22, 2022
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/448116 mentions this issue: internal/regtest/workspace: permanently skip TestDeleteModule_Interdependent

@findleyr findleyr self-assigned this Nov 4, 2022
@ma-hartma
Copy link

Hey there! Is there an alternative @findleyr? I really need this feature for working on monorepos and everything worked just fine over the last months of me using it.

@findleyr
Copy link
Contributor Author

findleyr commented Nov 6, 2022

@ma-hartma yes, as the error message hopefully suggests, the alternative is to upgrade to Go 1.18 or later, and use a go.work file at the root of your workspace.
https://github.com/golang/tools/blob/master/gopls/doc/workspace.md#go-workspaces-go-118

More info on go.work files here:
https://go.dev/ref/mod#go-work-file

gopherbot pushed a commit to golang/tools that referenced this issue Nov 7, 2022
…pendent

This test is flaky, likely due to some race in the
experimentalWorkspaceModule logic. Since we're about to delete support
for that experimental feature, simply skip the test to stop the flakes.

Leave the test as an artifact, as it will be deleted as part of the
clean up of experimentalWorkspaceModule. No need to delete it before
then.

Updates golang/go#55331
Fixes golang/go#55923

Change-Id: Ic17485e42e335459df462af00a2088812ecfb5f4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/448116
Reviewed-by: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Findley <rfindley@google.com>
komuw added a commit to komuw/hardstone that referenced this issue Dec 1, 2022
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/459635 mentions this issue: gopls/internal/lsp/cache: recreate Views when their root changes

gopherbot pushed a commit to golang/tools that referenced this issue Dec 29, 2022
A View is defined by a Go environment along with a go.work file, go.mod
file, or directory in GOPATH. When the environment changes via
didChangeConfiguration, we recreate the View. Before this CL we didn't
do the same when a view-defining go.mod or go.work was added or removed.
Instead, we relied on workspace and snapshot invalidation to get us to
the correct state. But since we reinitialize the view on these changes
anyway there is little value in preserving any existing view state, and
in fact doing so may lead to latent bugs. For example, deleting a
go.work file caused the workspace to fall back to 'file system' mode,
which may not be the same state that would result from restarting gopls.

This change also moves us toward a model where we can have a dynamic set
of views covering the full set of open files, not 1:1 with workspace
folders.

Also:
- move the dirURI helper function to span.Dir, which is more
  discoverable
- fix a bug where the wrong filter function was used to define the
  workspace
- remove Session.optionsOverride, which was unused

For golang/go#55331

Change-Id: Id108e848cdd942c34eda0a339d2c8a517c89c7de
Reviewed-on: https://go-review.googlesource.com/c/tools/+/459635
TryBot-Result: Gopher Robot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/459785 mentions this issue: gopls/internal/regtest: port experimental workspace tests to go.work

gopherbot pushed a commit to golang/tools that referenced this issue Dec 29, 2022
Now that experimental workspace mode is deprecated, re-express tests
that depended on this mode in terms of go.work files.

For golang/go#55331

Change-Id: I90a876319321fd99982d13d258b7653c337f035a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/459785
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/459789 mentions this issue: gopls/internal/lsp/cache: clean up view workspace information

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/458116 mentions this issue: gopls: remove the experimentalWorkspaceModule mode

gopherbot pushed a commit to golang/tools that referenced this issue Jan 12, 2023
Tracking of workspace information in the View contained several
inconsistencies and redundancies. Clean this up, with the following
changes:

- eliminate the View.rootURI, opting to derive it instead
- eliminate the View.explicitGowork field, instead using the view.gowork
  field and checking if it is outside of the workspace.
- eliminate many places where directory filters were interpreted
  relative to the rootURI. This is wrong: directory filters are
  expressed relative to the workspace folder.
- remove special handling of GOMODCACHE, now that we're on Go 1.16+
- rewrite the locateTemplateFiles function to use view.filterFunc and
  filepath.WalkDir (now that we're on Go 1.16+).
- don't request goimports env vars when loading environment variables
  for the view. They weren't being propagated to goimports anyway, and
  goimports will load them as needed.

For golang/go#55331

Change-Id: I5e7f7e77e86d9ae425d2feaff31030278fed8240
Reviewed-on: https://go-review.googlesource.com/c/tools/+/459789
Reviewed-by: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
leitzler added a commit to govim/govim that referenced this issue Feb 5, 2023
The experimental support for workspace module has been removed from
gopls (as per golang/go#55331). This change removes the setting from
govim as preparation before updating gopls to a version that doesn't
support workspace module.
leitzler added a commit to govim/govim that referenced this issue Feb 6, 2023
The experimental support for workspace module has been removed from
gopls (as per golang/go#55331). This change removes the setting from
govim as preparation before updating gopls to a version that doesn't
support workspace module.
rinchsan pushed a commit to rinchsan/gosimports that referenced this issue Feb 19, 2023
Tracking of workspace information in the View contained several
inconsistencies and redundancies. Clean this up, with the following
changes:

- eliminate the View.rootURI, opting to derive it instead
- eliminate the View.explicitGowork field, instead using the view.gowork
  field and checking if it is outside of the workspace.
- eliminate many places where directory filters were interpreted
  relative to the rootURI. This is wrong: directory filters are
  expressed relative to the workspace folder.
- remove special handling of GOMODCACHE, now that we're on Go 1.16+
- rewrite the locateTemplateFiles function to use view.filterFunc and
  filepath.WalkDir (now that we're on Go 1.16+).
- don't request goimports env vars when loading environment variables
  for the view. They weren't being propagated to goimports anyway, and
  goimports will load them as needed.

For golang/go#55331

Change-Id: I5e7f7e77e86d9ae425d2feaff31030278fed8240
Reviewed-on: https://go-review.googlesource.com/c/tools/+/459789
Reviewed-by: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
@harshitoshi
Copy link

I am using the 1.20.2 version, still getting the suggestion-
invalid settings: experimentalWorkspaceModule has been replaced by go workspaces, and will be removed in a future version of gopls (https://go.dev/issue/55331)
Is there any alternative??

@findleyr
Copy link
Contributor Author

findleyr commented Apr 3, 2023

@harshitoshi the alternative is currently to use a go.work file https://go.dev/ref/mod#go-work-file.

Shortly, we'll also support working on arbitrary modules as you open them: #57979.

@harshitoshi
Copy link

May I know why am I facing that issue.

@findleyr
Copy link
Contributor Author

findleyr commented Apr 3, 2023

@harshitoshi I'm not sure I understand: you are getting this message because you set the "experimentalWorkspaceModule" setting. That setting is deprecated, and has been replaced by go workspaces.

@amery
Copy link

amery commented Apr 8, 2023

@findleyr please don't remove experimentalWorkspaceModule, go.work doesn't work when one of your dependencies has an old version on go.mod.

e.g.

github.com/fatih/color
# github.com/rivo/uniseg
../../../pkg/mod/github.com/rivo/uniseg@v0.4.4/properties.go:137:21: type parameter requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../../pkg/mod/github.com/rivo/uniseg@v0.4.4/properties.go:137:34: embedding interface element [3]int|[4]int requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../../pkg/mod/github.com/rivo/uniseg@v0.4.4/properties.go:144:22: invalid operation: cannot index cpRange (variable of type E constrained by interface{[3]int|[4]int})
../../../pkg/mod/github.com/rivo/uniseg@v0.4.4/properties.go:148:22: invalid operation: cannot index cpRange (variable of type E constrained by interface{[3]int|[4]int})
../../../pkg/mod/github.com/rivo/uniseg@v0.4.4/properties.go:160:23: implicit function instantiation requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../../pkg/mod/github.com/rivo/uniseg@v0.4.4/properties.go:166:25: implicit function instantiation requires go1.18 or later (-lang was set to go1.16; check go.mod)
github.com/mgechev/revive/rule

@gaisuke
Copy link

gaisuke commented Nov 6, 2023

@findleyr please don't remove experimentalWorkspaceModule, go.work doesn't work when one of your dependencies has an old version on go.mod.

e.g.

github.com/fatih/color
# github.com/rivo/uniseg
../../../pkg/mod/github.com/rivo/uniseg@v0.4.4/properties.go:137:21: type parameter requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../../pkg/mod/github.com/rivo/uniseg@v0.4.4/properties.go:137:34: embedding interface element [3]int|[4]int requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../../pkg/mod/github.com/rivo/uniseg@v0.4.4/properties.go:144:22: invalid operation: cannot index cpRange (variable of type E constrained by interface{[3]int|[4]int})
../../../pkg/mod/github.com/rivo/uniseg@v0.4.4/properties.go:148:22: invalid operation: cannot index cpRange (variable of type E constrained by interface{[3]int|[4]int})
../../../pkg/mod/github.com/rivo/uniseg@v0.4.4/properties.go:160:23: implicit function instantiation requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../../pkg/mod/github.com/rivo/uniseg@v0.4.4/properties.go:166:25: implicit function instantiation requires go1.18 or later (-lang was set to go1.16; check go.mod)
github.com/mgechev/revive/rule

How to remove the experimentalWorkspaceModule in settings??

@findleyr
Copy link
Contributor Author

findleyr commented Nov 6, 2023

"experimentalWorkspaceModule" is not the way to have gopls behave correctly when a go.work cannot be used. The true solution is to have gopls automatically detect multiple separate workspaces to work on, and this is what we are doing in #57979, which I am hoping to land in master this month.

@gaisuke I'm not sure which LSP client you are using, so I don't know where settings are configured.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

6 participants