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: misleading error message when a dependency's go.mod is a symbolic link #40590

Open
jayconrod opened this issue Aug 5, 2020 · 2 comments
Open
Milestone

Comments

@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Aug 5, 2020

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 jayconrod added this to the Go1.16 milestone Aug 5, 2020
@jayconrod
Copy link
Contributor Author

@jayconrod jayconrod commented Aug 5, 2020

@bcmills
Copy link
Member

@bcmills bcmills commented Aug 6, 2020

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.