I won't be able to try your repro today but I suspect this is an issue with your Go installation. Can you set GOPACKAGESPRINTGOLISTERRORS=1 and attach the output?

Here it is:

$ GOPACKAGESPRINTGOLISTERRORS=1 goimports -w .
GOROOT=~/.gimme/versions/go1.11.4.linux.amd64 GOPATH=~/Dev/go GO111MODULE= PWD=~/Desktop/0ce7246431ace4c03a7ae82400ed9050 go [list -e -json -compiled -test=false -export=true -deps=true -- strings .] stderr: <<# github.com/thatguystone/foo
./foo.go:4:9: undefined: strings
>>
root package strings is missing```

Weird. I can't reproduce the problem, so I still think this is an issue with your installation of Go. But I'm not sure what it is.

Can you try running the command printed on the first line there? It should pretty much work if you strip the brackets off the arguments. We're expecting json output that doesn't include an entry for "strings" for some reason. It might also be interesting to run go install std to see if something weird happens there.

@matloob, @ianthehat in case they have any clue.

+1 on heschi's suggestion. I'm curious what the following command produces:

GOROOT=~/.gimme/versions/go1.11.4.linux.amd64 GOPATH=~/Dev/go GO111MODULE= PWD=~/Desktop/0ce7246431ace4c03a7ae82400ed9050 go list -e -json -compiled -test=false -export=true -deps=true -- strings .

Could you give us some information about what "gimme" is? If it's having trouble finding a standard library package, my guess is that it has to do with your GOROOT.

I dug into this a bit more, and it looks this happens when there's another package named "strings". I've updated the test case with a dependency that has such a package (specifically, it's github.com/gobwas/glob/util/strings).

0ce7246431ace4c03a7ae82400ed9050 $ mkdir ../go
0ce7246431ace4c03a7ae82400ed9050 $ export GOPATH=`pwd`/../go
0ce7246431ace4c03a7ae82400ed9050 $ go mod tidy
go: finding github.com/gobwas/glob v0.2.3
go: downloading github.com/gobwas/glob v0.2.3
0ce7246431ace4c03a7ae82400ed9050 $ goimports -w foo.go 
root package strings is missing

If I remove the dependency from foo.go, the problem doesn't go away.

0ce7246431ace4c03a7ae82400ed9050 $ cat go.mod
module github.com/thatguystone/foo

require github.com/gobwas/glob v0.2.3
0ce7246431ace4c03a7ae82400ed9050 $ go mod tidy
0ce7246431ace4c03a7ae82400ed9050 $ cat go.mod
module github.com/thatguystone/foo
0ce7246431ace4c03a7ae82400ed9050 $ goimports -w foo.go 
root package strings is missing

If I actually remove the package from the cache, then it works:

0ce7246431ace4c03a7ae82400ed9050 $ chmod u+rw -R ../go/pkg/mod/github.com/gobwas/
0ce7246431ace4c03a7ae82400ed9050 $ rm -rf !$
rm -rf ../go/pkg/mod/github.com/gobwas/
0ce7246431ace4c03a7ae82400ed9050 $ goimports -w foo.go

@heschik

Can you try running the command printed on the first line there? It should pretty much work if you strip the brackets off the arguments. We're expecting json output that doesn't include an entry for "strings" for some reason.

Output here: https://gist.github.com/thatguystone/0ce7246431ace4c03a7ae82400ed9050#file-golist-json

It might also be interesting to run go install std to see if something weird happens there.

Nothing weird happened there: it exited with status 0 and printed nothing.

@matloob

Could you give us some information about what "gimme" is? If it's having trouble finding a standard library package, my guess is that it has to do with your GOROOT.

gimme is the tool travis-ci uses to switch go versions for builds (https://github.com/travis-ci/gimme/)

Thanks for the excellent repro. I understand the problem now. It's a pretty simple bug in the guts of go/packages when a query finds the same package through multiple paths, in this case both via a module dependency and a module cache scan. Not sure how our tests missed this.

Anyway, I should have a CL soon, probably tomorrow.

Change https://golang.org/cl/155020 mentions this issue: go/packages: deduplicate roots