cmd/go: misleading error message when a dependency's go.mod is a symbolic link

[jayconrod]

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

$ go version
go version go1.15rc1 darwin/amd64

Does this issue reproduce with the latest release?

yes

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

go env Output

$ go env
go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/jayconrod/Library/Caches/go-build"
GOENV="/Users/jayconrod/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/jayconrod/Code/modcache"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/jayconrod/go"
GOPRIVATE=""
GOPROXY="direct"
GOROOT="/opt/go/installed"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/go/installed/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-build173749482=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

• Create a module where go.mod is a symbolic link to another file.
• Tag and publish a release, for example, https://github.com/jayconrod/modtest/tree/v0.0.0-symlink
• In a new module, add a requirement on the version with the symbolic link.
• Run any command that loads the build list.

What did you expect to see?

• If a module zip file is downloaded, there should be an error explaining that when the module zip file was created, go.mod was a symbolic link. Symbolic links aren't included in zip files, so this should be an error.
• If only go.mod is downloaded, there should be a similar error. We use git cat-file to extract go.mod from a repository without checking other constraints, but we should check for this.
• This should be documented in golang.org/x/mod/zip.
• gorelease should report an error for this condition.

Alternatively, we could make this work without error by changing the command used to extract go.mod files from repositories. For Git, we use git cat-file without --follow-symlinks, which that prints the name of the file the link points to (resulting in weird error messages. If we used --follow-symlinks then the go.mod file would be usable by MVS but not included in the zip file.

What did you see instead?

$ go build
go: github.com/jayconrod/modtest@v0.0.0-symlink: go.mod is missing module path at revision v0.0.0-symlink

[jayconrod]

cc @bcmills @matloob

[bcmills]

If we did allow go.mod to be a symlink, we would have to be careful about replacements: the main module's go.mod file must not alias the go.mod files of any of its dependencies (via symlinks in either direction), or else our dependency analysis will be wrong (#34417).

[odeke-em]

Kindly pinging you @jayconrod @bcmills @matloob, shall we punt this to Go1.17 or is there something else we can do for Go1.16? Thank you.

[jayconrod]

Moving to Go1.17. I have a partially written CL for this, but it's surprisingly difficult to tell whether a file is a symbolic link in all supported VCS tools without checking out the whole revision. This will probably only be fixed for git and hg. I'm not sure it's possible for svn, and I haven't looked at fossil or bzr.

[ianlancetaylor]

Are we going to do anything here for 1.17? Thanks.