cmd/go: Go not traversing symlinks

[krisnova]

V 1.6.2 Darwin/AMD64

# My project lives here
cd ~/myproject

# My $GOPATH is ~/gopath
echo $GOPATH
/Users/kris/gopath

# Symlink my project into $GOPATH
ln -s ~/myproject $GOPATH/src/myproject
go install $GOPATH/src/myproject/...

#This error message
warning: "/Users/kris/gopath/myproject/..." matched no packages

I would expect go to respect and follow the symlink and traverse the path as it would with a hardlink.

[as]

The go command uses filepath.Walk to match packages, and filepath.Walk does not follow symbolic links at this time.

Changing this means either modifying filepath.Walk or creating a custom walk that resolves symbolic links.

I would not encourage the first option on due to Compatibility guidelines. I rely on filepath.Walk behavior not to follow symlinks, and on many Linux systems I use this would cause circular non-terminating traversals.

$GOROOT/src/cmd/go/main.go:560,561:        fmt.Fprintf(os.Stderr, "warning: %q matched no packages\n", pattern)
$GOROOT/src/cmd/go/main.go:565,566:        func matchPackages(pattern string) []string {
$GOROOT/src/cmd/go/main.go:590,591:            filepath.Walk(root, func(path string, fi os.FileInfo, err error) error {

go doc filepath.Walk
func Walk(root string, walkFn WalkFunc) error
    Walk walks the file tree rooted at root, calling walkFn for each file or
    directory in the tree, including root. All errors that arise visiting files
    and directories are filtered by walkFn. The files are walked in lexical
    order, which makes the output deterministic but means that for very large
    directories Walk can be inefficient. Walk does not follow symbolic links.

[krisnova]

Ah thanks for the response @as - this makes a lot more sense now. I would say it's safe to set this is a nuisance more than anything else. But I still am curious if the issue needs to be addressed?

Is the ability to follow symlinks in this context something we would like to see in a later version of go?

[as]

There was a proposal to add this feature in May, but it was declined. The reason is that symlinks introduce too much complexity and aren't worth their trouble.

I agree with the reason. The symlinks on my Linux systems were created by the distribution builders and I personally avoid them. If you're unable to use hard links, maybe 'mount -o bind' can solve your problem by approximating a namespace in Linux.

[rsc]

Like in #15507, we're not going to attempt this. It creates too many other issues. You could instead symlink ~/myproject -> your GOPATH. Apologies.