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

cmd/go: regression in "go get" with relative paths #20175

Closed
kevinburke opened this issue Apr 29, 2017 · 7 comments
Closed

cmd/go: regression in "go get" with relative paths #20175

kevinburke opened this issue Apr 29, 2017 · 7 comments
Milestone

Comments

@kevinburke
Copy link
Contributor

kevinburke commented Apr 29, 2017

Please answer these questions before submitting your issue. Thanks!

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

Tip (go version devel +c4335f81a2 Fri Apr 28 23:38:15 2017 +0000 darwin/amd64)

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

Mac

What did you do?

export GOPATH=/Users/kevin
mkdir -p "$GOPATH/src/github.com/kevinburke"
pushd "$GOPATH/src/github.com/kevinburke"
    rm -rf rest # just to make sure it's empty
    go get ./rest
popd

What did you expect to see?

I expected github.com/kevinburke/rest to get cloned from Github and checked out to $GOPATH/src/github.com/kevinburke/rest. (You should be able to reproduce this problem with any relative path, there's nothing specific to this repository)

This is the behavior of Go 1.5 through Go 1.8 (didn't test earlier versions than this).

What did you see instead?

$ go get ./rest
can't load package: package ./rest: cannot find package "./rest" in:
	/Users/kevin/src/github.com/kevinburke/rest

My apologies as I believe someone was working on this previously, but I searched the issue history for related terms and couldn't find anything about it.

@bradfitz bradfitz added this to the Go1.9 milestone Apr 29, 2017
@bradfitz bradfitz added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 29, 2017
@vcabbage
Copy link
Member

vcabbage commented May 1, 2017

Bisected this to #17863 (https://golang.org/cl/33158/).

@ianlancetaylor
Copy link
Contributor

CC @shurcooL

@dmitshur
Copy link
Contributor

dmitshur commented May 1, 2017

Thanks for the report, I'll be able to investigate this fully tomorrow (and happy to send a CL).

From a brief look at this issue, it looks like cmd/go is still relying on the previous behavior of go/build, before #17863 was fixed, during the process of go geting relative import paths. It needs to be updated to take into account the post-#17863-fixed behavior of go/build.

@dmitshur dmitshur self-assigned this May 1, 2017
@rsc
Copy link
Contributor

rsc commented May 1, 2017

Why not just roll back the incompatible change made for #17863?

@gopherbot
Copy link

CL https://golang.org/cl/42350 mentions this issue.

@dmitshur
Copy link
Contributor

dmitshur commented May 1, 2017

Why not just roll back the incompatible change made for #17863?

It's possible to do that, but it seems it would take more steps. That change was merged 2 months ago. If rolled back now, it would break x/tools/cmd/godoc tests. Since it's clear where the problem is, it's possible to fix this issue directly. But I can act differently if advised so.

The problem is that cmd/go relies on previous behavior of build.Import that was not tested. Specifically:

// If the path is a local import path naming a package that can be imported
// using a standard import path, the returned package will set p.ImportPath
// to that path.

In combination with:

// If an error occurs, Import returns a non-nil error and a non-nil
// *Package containing partial information.

In the case of local import path pointing to a directory that doesn't exist, that behavior was broken by the change in CL 33158.

A fix I've come up with is to bring back that previous behavior of build.Import and add tests for it. This can be done without re-introducing #17863 issue, so tests for that continue to pass.

I've sent CL 42350, @rsc, can you comment on how it looks?

For reference, here are all uses of FindOnly flag in GOROOT.


These are the two uses of FindOnly flag in cmd/go/.... Both ignore error and use ImportPath field only:

if build.IsLocalImport(arg) {
	bp, _ := cfg.BuildContext.ImportDir(filepath.Join(base.Cwd, arg), build.FindOnly)
	if bp.ImportPath != "" && bp.ImportPath != "." {
		arg = bp.ImportPath
	}
}
if build.IsLocalImport(arg) {
	cwd, _ := os.Getwd()
	bp, _ := cfg.BuildContext.ImportDir(filepath.Join(cwd, arg), build.FindOnly)
	if bp.ImportPath != "" && bp.ImportPath != "." {
		arg = bp.ImportPath
	}
}

(There are 4 other instances in all of GOROOT code. One in cmd/cover, one in go/internal/gcimporter, and two in go/internal/srcimporter. These shouldn't be relevant because, unlike cmd/go, they deal with Go packages whose directories exist.)

@dmitshur
Copy link
Contributor

@rsc, did you see my comment above? This is related to #19769 and CL https://go-review.googlesource.com/c/33158/#message-93b2fc6b74efcb9936bc119782ee3485ca897450.

@dmitshur dmitshur removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 15, 2017
@golang golang locked and limited conversation to collaborators Aug 11, 2018
@rsc rsc unassigned rsc and dmitshur Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants