Go: cmd/go: allow <meta> tags to override version tag prefixes for submodules

[ucirello]

Please answer these questions before submitting your issue. Thanks!

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

go version go1.10.3 linux/amd64 vgo:devel +88c76dcbab
go version go1.11beta2 darwin/amd64

Does this issue reproduce with the latest release?

Yes

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/uldericofilho/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/uldericofilho/src/strongdm"
GOPROXY=""
GORACE=""
GOROOT="/Users/uldericofilho/sdk/go1.11beta2"
GOTMPDIR=""
GOTOOLDIR="/Users/uldericofilho/sdk/go1.11beta2/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/uldericofilho/src/strongdm/src/github.com/ucirello/gomod-submod-bug/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/_l/9yb78fmx0jzb8khycvrzw3qw0000gn/T/go-build292047428=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Reproduction script:
https://github.com/ucirello/gomod-submod-bug/blob/master/test.sh

Log at:
https://github.com/ucirello/gomod-submod-bug/blob/master/test.log

What did you expect to see?

When running go get, I expected to see cirello.io/[email protected] to be imported instead of v0 placeholder.
When manually changing go.mod to require cirello.io v1.1.8, I would expect modules system to pull [email protected] and extract cirello.io/errors from it.

What did you see instead?

The builder breaks.

[ianlancetaylor]

CC @bcmills

[bcmills]

This is working as designed: see the “Multiple-Module Repositories” section of https://research.swtch.com/vgo-module.

The go command interprets the v1.1.8 tag on the repository github.com/ucirello/public as applying to the module github.com/ucirello/public. For the module stored in github.com/uricello/public/errors, we expect to see a repository tag with the prefix errors/, such as errors/v1.1.8.

Perhaps we could fall back to versions without a prefix if there are no versions tagged with the prefix, but then what happens if a prefixed tag is added later? If you added the tag errors/v1.0.0 to the revision tagged v1.1.8, then the meaning of cirello.io/[email protected] would change: we certainly can't allow that.

[bcmills]

Your use-case is interesting, though: you're using a <meta> HTML tag to point into the repository, not serving straight out of that repository. Perhaps we could allow the <meta> HTML tag to explicitly override the prefix that the go command uses for version tags.

I'll leave that for @rsc to decide.

[rsc]

Sorry, but this is working as intended.

I understand why you'd want to do that, but part of the design here is to allow a single repo to contain modules at different versions. If the repo corresponds to cirello.io (as in this case), then to tag a specific version of cirello.io/errors as v1.1.8, you need to create an errors/v1.1.8 tag.

And because there is an errors/go.mod file, the module cirello.io does _not_ contain that directory. Modules do not contain other modules.

For all but power users, you probably want to adopt the usual convention that one repo = one module. It's important for long-term evolution of code storage options that a repo _can_ contain multiple modules, but it's almost certainly not something you want to do by default. We will be writing a doc at some point about how and how not to arrange multiple modules in a single repo.