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.
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: firstname.lastname@example.org: go.mod is missing module path at revision v0.0.0-symlink
The text was updated successfully, but these errors were encountered:
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).
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.