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

$ go version
go version go1.12.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
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/matt/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/matt/Dev"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
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/sf/7w4p15_15jb59d7kwy0wglh40000gn/T/go-build796937585=/tmp/go-build -gno-record-gcc-switches -fno-common"

What are you trying to do?

(Added this question, hope that's OK.)

go get a Go project's source code and install its command (the repo contains both a command and library packages) while respecting module dependencies.

In the past we used vendor to pin dependencies, but we'd rather use Go modules. go get has always worked great, even with an empty GOPATH. If possible, we'd like for the project to stay go-gettable.

What did you do?

1. Make an empty GOPATH. (or, as I did, export GOPATH= and ensure no ~/go folder exists)
2. $ GO111MODULE=on go get github.com/mholt/testrepo/caddy

What did you expect to see?

The $GOPATH/src (~/go/src) folder populated with the project's source code, and the binary installed to the bin folder, while honoring the versions specified in go.mod.

What did you see instead?

Only module folders were created.

How does one get the source code, with dependencies, while honoring go.mod?

The one-step install flow of go get was really nice. Will this no longer be the case with Go 1.13 when GO111MODULE=on becomes the default behavior?

More info

We're in an awkward position in our transition to modules. Many people are unable to build Caddy from source without some wrangling.

We've added go.mod and go.sum, removed our vendor folder, and tagged a beta release (in the actual repo, not my test repo here). Unfortunately, modules seem to ignore the beta release tag so all module operations fail unless we explicitly specify the beta version in our commands. So it is not obvious how to test that we've transitioned correctly.

Additionally, without modules (GO111MODULE=off), running go get on Caddy currently fails with:

package github.com/lucas-clemente/quic-go/h2quic: cannot find package "github.com/lucas-clemente/quic-go/h2quic" in any of:
	/usr/local/go/src/github.com/lucas-clemente/quic-go/h2quic (from $GOROOT)
	/Users/matt/go/src/github.com/lucas-clemente/quic-go/h2quic (from $GOPATH

because one of our upstream dependencies have had a breaking change. Our go.mod pins the working version of this dependency, but go get does not honor this (yet?).

But setting GO111MODULE=on also doesn't work because the beta version isn't recognized. The last non-prerelease tag doesn't use modules, so the build also fails.

(As an aside, @v1.0.0-beta1 needs to be specified explicitly, which (temporarily?) breaks our build instructions and isn't obvious... it confused a lot of people including me.)

Even still, if we start over on the test repo but set GO111MODULE=on this time, it does not pull down the source code so we can start developing on it.

If go get is how the GOPATH is populated for development, it should put the source code in it so we can develop with it. If go get becomes a command for a read-only workflow, what is the alternative for "developers" as opposed to just "builders"?