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: go vet ./... does not correctly resolve symlinks for the top directory #12556

Closed
devoid opened this issue Sep 9, 2015 · 4 comments
Closed

Comments

@devoid
Copy link

devoid commented Sep 9, 2015

What version of Go are you using (go version)?
go version go1.4.2 darwin/amd64

What operating system and processor architecture are you using?
OS X 10.10.5, amd64

What did you do?

$ export GOPATH=$HOME/projects/go-workspace
$ cd $GOPATH/src/github.com/devoid/foobar 
$ go vet ./...
$
$ ln -s $GOPATH/src/github.com/devoid/foobar $HOME/projects/foobar
$ cd $HOME/projects/foobar
$ go vet ./...
vet: error walking tree: stat ../go-workspace/src/github.com/devoid/foobar/main.go: no such file or directory
vet: ../go-workspace/src/github.com/devoid/foobar/main.go: open ../go-workspace/src/github.com/devoid/foobar/main.go: no such file or directory
vet: no files checked
exit status 1

What did you expect to see?
Many other go commands go tool cover, godoc and go work fine with this sort of symlink setup.

What did you see instead?
I am not entirely sure. The go vet command appears to identify the symlink but can't find the files in it?

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Sep 9, 2015
@ianlancetaylor ianlancetaylor changed the title go vet ./... does not correctly resolve symlinks for the top directory cmd/go: go vet ./... does not correctly resolve symlinks for the top directory Sep 9, 2015
@robpike
Copy link
Contributor

robpike commented Sep 9, 2015

Symlinks are problematic with these tools. I'm not sure it can be made to work in all cases, or that it's worth trying.

We encourage avoiding symlinks in the Go tree.

@gopherbot
Copy link

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

@nmiyake
Copy link
Contributor

nmiyake commented Sep 13, 2016

I would like to echo that this issue is problematic for our team. Totally fine with this being the default behavior, but the issue is exacerbated by the difficulty of working around it in Go.

Initially, we tried working around this by launching a new Go process that would invoke go vet with a path that we resolved ourselves. Simplified example:

wd, _ := os.Getwd() // path may be a symlink
wd, _ = filepath.EvalSymlinks(wd) // this path is always absolute
cmd := exec.Command("go", "vet")
cmd.Dir = wd // set working directory of command to explicitly be absolute path
cmd.Run() // doesn't work -- os.Getwd() in relPaths() still returns symlink path

However, this still doesn't work -- the os.Getwd() call in the relPaths function of build.go still returns the symlink path. It appears that this technically doesn't violate any contracts since os.Getwd() states: "If the current directory can be reached via multiple paths (due to symbolic links), Getwd may return any one of them.", but is definitely unintuitive (since the path is explicitly set to be absolute).

We're working around this for now by taking advantage of the fact that os.Getwd() consults $PWD first, so setting cmd.Env = append([]string{fmt.Sprintf("PWD=%v", wd)}, os.Environ()...) works causes this to work as expected. However, we know this is not ideal since it ties the behavior to an undocumented implementation detail that could change at any time.

So, long story short, I second that it would be nice to fix this issue -- although I agree and understand that symlinks into the Go path tree should be avoided, it would be nice to have the option to at least have a plausible work-around to handle this for tools that want to offer a more user-friendly experience.

@gopherbot
Copy link

Change https://golang.org/cl/74750 mentions this issue: cmd/go: pass package config to vet during "go vet"

@golang golang locked and limited conversation to collaborators Nov 1, 2018
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

5 participants