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: "no dep handle" on import #37786

Closed
atombender opened this issue Mar 10, 2020 · 9 comments
Closed

x/tools/gopls: "no dep handle" on import #37786

atombender opened this issue Mar 10, 2020 · 9 comments
Labels
Milestone

Comments

@atombender
Copy link

@atombender atombender commented Mar 10, 2020

What version of Go are you using (go version)?

$ go version
go version go1.14 darwin/amd64

$ gopls version
golang.org/x/tools/gopls v0.3.3
    golang.org/x/tools/gopls@(devel)

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/alex/Library/Caches/go-build"
GOENV="/Users/alex/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY="github.com/t11e/*"
GONOSUMDB="github.com/t11e/*"
GOOS="darwin"
GOPATH="/Users/alex/.go"
GOPRIVATE="github.com/t11e/*"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/opt/go/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/opt/go/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/alex/Code/golang-tools/gopls/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/qs/wpmg19r12_9_nz7pvvs2_82r0000gn/T/go-build173891991=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Use gopls via the Go extension for VSCode.

What did you expect to see?

Language server should work.

What did you see instead?

Import of the package github.com/vmihailenco/msgpack/v4 is flagged with error "could not import":

Screen Shot 2020-03-10 at 17 56 53

Log from gopls has this rather obscure error:

[Info  - 5:55:10 PM] 2020/03/10 17:55:10 go/packages.Load
	snapshot = 1
	package = command-line-arguments_test
	files = [/Users/alex/Projects/Scratch/binarydatatesting/benchmark_test.go]
2020/03/10 17:55:10 no dep handle: no metadata for github.com/vmihailenco/msgpack/v4
	package = github.com/vmihailenco/msgpack/v4

(Not sure where package = command-line-arguments_test comes from.) I also get this error as a VSCode notification:

You are neither in a module nor in your GOPATH. Please see https://github.com/golang/go/wiki/Modules for information on how to set up your Go project.

The module builds just fine.

Complete folder: testcase.tar.gz

gopls log: gopls.log

If I remove the import, the import error goes away, but I still get the "You are neither in a module nor in your GOPATH" error. Here is the gopls log from that: gopls-2.log.

The error seems unrelated to that specific import, github.com/vmihailenco/msgpack/v4. It also happens if I add a nested package to my module.

@gopherbot gopherbot added this to the Unreleased milestone Mar 10, 2020
@gopherbot
Copy link

@gopherbot gopherbot commented Mar 10, 2020

Thank you for filing a gopls issue! Please take a look at the Troubleshooting guide, and make sure that you have provided all of the relevant information here.

@atombender
Copy link
Author

@atombender atombender commented Mar 11, 2020

Could this be related to some kind of state written under $GOPATH/pkg?

I was curious if anything under my current $GOPATH setting (which is, and always has been, $HOME/.go, but which is not the same as the location where I store projects) would affect things. So I unset $GOPATH and restarted VSCode, which appears to make gopls assume a default of $HOME/go (no dot), which did not previously exist. When doing this, I no longer got the original error as described above.

I expected to get the original error again when I then reverted back to setting $GOPATH to $HOME/.go, but this didn't happen. I can no longer reproduce the error that I reported.

I'm not sure how to explain that. And I have to emphasize that while trying to figure out the original error, I reloaded VSCode and gopls many, many times, never being able to resolve the issue.

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Mar 11, 2020

What directory are you opening? I'm not able to reproduce the issue when opening VS Code at the directory containing the go.mod file. Based on your logs, it seems that gopls was not picking up the go.mod file, and it needs to be opened in the module to do so.

In general, gopls does not yet work well with nested modules, but that's something we're working on fixing before gopls/v1.0.0.

@stamblerre stamblerre modified the milestones: Unreleased, gopls/v0.4.0 Mar 11, 2020
@atombender
Copy link
Author

@atombender atombender commented Mar 11, 2020

I think that's the cause: Initially I opened the parent folder. I have a "scratch" folder I keep permanently open in VSCode where I put folders whenever I need to do some temporary experimentation. The scratch folder doesn't have a go.mod:

$ ls -lR ~/Projects/Scratch
/Users/alex/Projects/Scratch:
total 0
drwxr-xr-x 8 alex staff 256 Mar 10 19:47 binarydatatesting

/Users/alex/Projects/Scratch/binarydatatesting:
total 228
-rw-r--r-- 1 alex staff    638 Mar 10 20:05 benchmark_test.go
-rw-r--r-- 1 alex staff 215217 Mar 10 16:15 data.json
-rw-r--r-- 1 alex staff    106 Mar 10 19:55 go.mod
-rw-r--r-- 1 alex staff   2293 Mar 10 19:55 go.sum

I opened it again, and can confirm that this reproduces the error.

Does this mean gopls only works with VSCode if the window's root folder is the one that contains go.mod? Can't gopls just look for the nearest file in the current directory or any of its parents?

@atombender
Copy link
Author

@atombender atombender commented Mar 11, 2020

If it's not supported, I propose that the VSCode Go extension checks for the scenario and warns about it, since it seems totally broken?

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Mar 11, 2020

That is the purpose of the warning you saw:

You are neither in a module nor in your GOPATH. Please see https://github.com/golang/go/wiki/Modules for information on how to set up your Go project.

@atombender
Copy link
Author

@atombender atombender commented Mar 11, 2020

But I am in a module. It's just that it's not the root of the VSCode workspace. There's a big difference.

This isn't an unusual structure, either. For example, a project like flatbuffers has all its Go files in a subfolder of the root, because the whole project supports many languages. Flatbuffers doesn't have a go.mod, but if it did, it would be under the go folder.

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Mar 11, 2020

I agree that it's not an unusual structure, gopls just doesn't yet have good support for it yet. You can check out #37720 and https://github.com/golang/proposal/blob/master/design/37720-gopls-workspaces.md for more details on our plans to address this.

The warning indicates that gopls will not work well in the given configuration. The work-around is to add each folder to the workspace individually (in VS Code, for example, there is File -> Add Folder to Workspace.

@atombender
Copy link
Author

@atombender atombender commented Mar 12, 2020

I understand, thanks.

I've actually gotten the GOPATH warning a lot recently in projects that do have a go.mod at its root, but gopls is so buggy overall (I probably forcibly restart it 40-50 a day), and it's just conditioned me into thinking of the warning as a false positive. I'll try to file an issue next time I see it.

@atombender atombender closed this Mar 12, 2020
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.