x/tools/go/packages: 'go list -e -json' for a directory without .go source files doesn't show module-relative import path #33157

jayconrod · 2019-07-17T19:20:32Z

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

$ go version
go version devel +6bf2767cc87 Tue Jul 16 15:37:25 2019 +0000 darwin/amd64

Does this issue reproduce with the latest release?

no, only on tip

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

go env Output

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/jayconrod/Library/Caches/go-build"
GOENV="/Users/jayconrod/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/var/folders/rq/x0692kqj6ml8cvrhcqh5bswc008xj1/T/tmp.6IPWXRqB"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org"
GOROOT="/Users/jayconrod/Code/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/jayconrod/Code/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/jayconrod/Code/test/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/rq/x0692kqj6ml8cvrhcqh5bswc008xj1/T/go-build053820400=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

$ go mod init m
$ go list -e -json $(pwd)

What did you expect to see?

The ImportPath field should be set to the expected import path of the directory.

{
	"ImportPath": "m",
	"Match": [
		"/Users/jayconrod/Code/test"
	],
	"Incomplete": true,
	"Error": {
		"ImportStack": [
			"m"
		],
		"Pos": "",
		"Err": "unknown import path \"m\": package m is not in the main module (m)"
	}
}

What did you see instead?

ImportPath is set to the absolute path of the directory instead.

{
	"ImportPath": "/Users/jayconrod/Code/test",
	"Match": [
		"/Users/jayconrod/Code/test"
	],
	"Incomplete": true,
	"Error": {
		"ImportStack": [
			"/Users/jayconrod/Code/test"
		],
		"Pos": "",
		"Err": "unknown import path \"/Users/jayconrod/Code/test\": cannot find package"
	}
}

Other notes

golang.org/x/tools/go/packages relies on the old behavior for packages with new files that are edited but not saved yet.

New behavior was likely introduced in CL 185417.

The text was updated successfully, but these errors were encountered:

jayconrod · 2019-07-17T19:21:18Z

cc @stamblerre @bcmills

bcmills · 2019-07-17T19:26:57Z

go/packages should not be relying on this behavior: it's extremely fragile.

What happens if the main module is example.com/m and has a requirement on module example.com which actually contains the package example.com/m?

jayconrod · 2019-07-17T19:35:03Z

I'll work with @stamblerre more to figure out exactly why it's doing this and what should happen instead. In general, I think they mainly need a way to map a directory to an import path.

stamblerre · 2019-07-17T23:37:18Z

Yes, exactly. Editors like Vim might not write anything to disk for a while, but the user will still be editing their file. We need some way to guess an import path given a directory. The code in go/packages that does this is here, and it only works because, previously, go list returned the "guess" of what that directory's import path was.

andybons · 2019-07-30T21:14:57Z

Moving to 1.14 as this isn't a release-blocker. Feel free to bump it back if it becomes one.

stamblerre · 2019-07-31T19:04:30Z

I think that this will actually have to be a release blocker for 1.13, because it will completely break the gopls overlay behavior. We need some kind of resolution here - was our conclusion that go/packages should do the work of resolving the import path?

jayconrod · 2019-07-31T20:28:10Z

I think this should be fixed in go/packages. It should be done before 1.13 ships though.

In general, overlays can't be processed by underlying build systems. If a package only exists in the overlay (not on disk) the driver needs to be smart enough to create new packages for it. The driver will also need to suppress errors for packages that are empty or incomplete because the overlay wasn't present.

stamblerre · 2019-08-01T20:15:03Z

Makes sense. We will move the logic into go/packages.

/cc @matloob

gopherbot · 2019-08-02T20:26:18Z

Change https://golang.org/cl/188764 mentions this issue: go/packages: handle case when go list returns absolute ImportPath

gopherbot · 2019-08-05T22:23:30Z

Change https://golang.org/cl/189038 mentions this issue: internal/lsp/testdata: delete nodisk/newdisk_exists.go

It should work now that go packages accepts go1.13's new go list behavior. Updates golang/go#33157 Change-Id: I1780210b414bc0556e10e10c8c775fbfd2922b2e Reviewed-on: https://go-review.googlesource.com/c/tools/+/189038 Run-TryBot: Michael Matloob <matloob@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>

jayconrod added NeedsFix The path to resolution is known, but the work has not been done. GoCommand cmd/go release-blocker labels Jul 17, 2019

jayconrod added this to the Go1.13 milestone Jul 17, 2019

jayconrod self-assigned this Jul 17, 2019

jayconrod added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed NeedsFix The path to resolution is known, but the work has not been done. release-blocker labels Jul 17, 2019

stamblerre mentioned this issue Jul 18, 2019

x/tools/internal/lsp: nodisk test broken at tip #33125

Closed

andybons modified the milestones: Go1.13, Go1.14 Jul 30, 2019

jayconrod mentioned this issue Jul 30, 2019

x/tools/internal/imports: tests broken with go/packages on tip #33175

Closed

jayconrod changed the title ~~cmd/go: 'go list -e -json /absolute/path' doesn't show correct import path~~ x/tools/go/packages: 'go list -e -json /absolute/path' doesn't show correct import path Jul 31, 2019

jayconrod added NeedsFix The path to resolution is known, but the work has not been done. and removed GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jul 31, 2019

jayconrod modified the milestones: Go1.14, Go1.13 Jul 31, 2019

jayconrod added the release-blocker label Jul 31, 2019

gopherbot closed this as completed in golang/tools@c5a2fd3 Aug 5, 2019

bcmills mentioned this issue Aug 27, 2019

cmd/cover: cannot run in directory with no .go files #33855

Closed

bcmills mentioned this issue Dec 6, 2019

cmd/go: go list reports a mangled ImportPath for a relative path that is not a valid Go package #36008

Closed

bcmills changed the title ~~x/tools/go/packages: 'go list -e -json /absolute/path' doesn't show correct import path~~ x/tools/go/packages: 'go list -e -json /absolute/path' doesn't show module-relative import path Dec 6, 2019

bcmills changed the title ~~x/tools/go/packages: 'go list -e -json /absolute/path' doesn't show module-relative import path~~ x/tools/go/packages: 'go list -e -json' for an empty directory doesn't show module-relative import path Dec 6, 2019

bcmills changed the title ~~x/tools/go/packages: 'go list -e -json' for an empty directory doesn't show module-relative import path~~ x/tools/go/packages: 'go list -e -json' for a directory without .go source files doesn't show module-relative import path Dec 6, 2019

golang locked and limited conversation to collaborators Dec 5, 2020

gopherbot added the FrozenDueToAge label Dec 5, 2020

rsc unassigned jayconrod Jun 23, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

x/tools/go/packages: 'go list -e -json' for a directory without .go source files doesn't show module-relative import path #33157

x/tools/go/packages: 'go list -e -json' for a directory without .go source files doesn't show module-relative import path #33157

jayconrod commented Jul 17, 2019

jayconrod commented Jul 17, 2019

bcmills commented Jul 17, 2019

jayconrod commented Jul 17, 2019

stamblerre commented Jul 17, 2019

andybons commented Jul 30, 2019

stamblerre commented Jul 31, 2019

jayconrod commented Jul 31, 2019

stamblerre commented Aug 1, 2019

gopherbot commented Aug 2, 2019

gopherbot commented Aug 5, 2019

x/tools/go/packages: 'go list -e -json' for a directory without .go source files doesn't show module-relative import path #33157

x/tools/go/packages: 'go list -e -json' for a directory without .go source files doesn't show module-relative import path #33157

Comments

jayconrod commented Jul 17, 2019

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

Other notes

jayconrod commented Jul 17, 2019

bcmills commented Jul 17, 2019

jayconrod commented Jul 17, 2019

stamblerre commented Jul 17, 2019

andybons commented Jul 30, 2019

stamblerre commented Jul 31, 2019

jayconrod commented Jul 31, 2019

stamblerre commented Aug 1, 2019

gopherbot commented Aug 2, 2019

gopherbot commented Aug 5, 2019

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

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