go get on a module gets incomplete files in to go/pkg/mod

[dayadev]

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

go version go1.13.4 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

GO111MODULE=""

GOARCH="amd64"

GOEXE=""

GOFLAGS="-insecure"

GOHOSTARCH="amd64"

GOHOSTOS="darwin"

GONOPROXY=""

GONOSUMDB=""

GOOS="darwin"

GOPRIVATE=""

GOPROXY="https://proxy.golang.org,direct"

GOROOT="/usr/local/Cellar/go/1.13.4/libexec"

GOSUMDB="sum.golang.org"

GOTMPDIR=""

GOTOOLDIR="/usr/local/Cellar/go/1.13.4/libexec/pkg/tool/darwin_amd64"

GCCGO="gccgo"

AR="ar"

CC="clang"

CXX="clang++"

CGO_ENABLED="1"

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/_4/g37z5y0j0t7dppmsyxymdsx00000gn/T/go-build977671086=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I am working on repository with two modules and structure is as follows

In the above modulelib repo, I have two modules
Module 1

module module.com/modulelib/modulelibone

go 1.13

require github.com/sirupsen/logrus v1.4.2

Module 2

module module.com/modulelib/modulelibtwo

go 1.13

require github.com/sirupsen/logrus v1.4.2

I have versioned the above module with one tag each modulelibone/v1.0.0 and modulelibtwo/v1.0.0 and published them

Now when I do a
go get module.com/modulelib/modulelibone

V1.0.0 is downloaded successfully for it be used as follows

go: finding module.com/modulelib/modulelibtwo latest
go: downloading module.com/modulelib/modulelibtwo v1.0.0
go: extracting module.com/modulelib/modulelibtwo v1.0.0

What did you expect to see?

I expected the go get to extract the modules into go/pkg/mod

What did you see instead?

It did extract into go/pkg/mod/module.com but only partially extracting only the files at the root of the repo ie., readme and test, and did not extract the sub directories with modules as shown below

[bcmills]

Each go.mod file defines the boundary of a new module. So the module at the root does not contain the two other modules in the repo: they share a common prefix, but are independent modules.

We've found that for most developers, it is simplest to stick to a single module per repo.

[bcmills]

We definitely need to improve the documentation for this, but it appears that the tooling is working as designed.

[bcmills]

Duplicate of #33637

[dayadev]

Each go.mod file defines the boundary of a new module. So the module at the root does not contain the two other modules in the repo: they share a common prefix, but are independent modules.

We've found that for most developers, it is simplest to stick to a single module per repo.

Are you saying that we also need a module at the root with the prefix module.com/modulelib

[miguelut]

Yeah @bcmills in the example there is no go.mod file at the root. The situation doesn't seem to match up with your response.

Unrelated -- I understand that the "official" recommendation is to host one module per repo, but this is impractical for some enterprises due to policy and political reasons that require use of, for instance, a mono-repo.

[miguelut]

I would also add some additional context to this which I'm not sure is relevant -- the repo @dayadev is using is an internal enterprise repo (Stash) which is running on a non-standard port (8443). So we wrote a small "meta tag server" which sits at "module.com" which serves up the meta tags as we understand them based on this article. This appears to at least be partially working since go get can get at least part of the module. So even though there is no go.mod file in the root -- could this strange behavior be explained by incorrect logic in our meta tag server?

[bcmills]

could this strange behavior be explained by incorrect logic in our meta tag server?

Yes, that is quite possible. Perhaps the import-prefix portion of your <meta name="go-import" […]> tag is listing the full module path instead of the path corresponding to the root of the repo?

[miguelut]

@bcmills Bingo. There either isn't another source that says that or it's so deeply buried that we missed it in the voluminous guides/articles/specs we've read over the past week or so. Appreciate the insight!

[bcmills]

The prefix detail is described at https://golang.org/cmd/go/#hdr-Remote_import_paths, but that's admittedly pretty deeply buried. (We've got some doc cleanup to do...)