go: cmd/go: '"bzr": executable file not found in $PATH' when fetching github.com/influxdata/platform

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

go version go1.11.4 freebsd/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output

GOARCH="amd64"
GOBIN="/data/go/bin"
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="freebsd"
GOOS="freebsd"
GOPATH="/data/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/freebsd_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/data/go/src/github.com/multiplay/go/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=/tmp/go-build442059268=/tmp/go-build -gno-record-gcc-switches"

What did you do?

GO111MODULE=on go get -u=patch

GO111MODULE=on go mod vendor

What did you expect to see?

I expected the commands to succeed.

What did you see instead?

go: launchpad.net/gocheck@v0.0.0-20140225173054-000000000087: bzr branch --use-existing-dir https://launchpad.net/~niemeyer/gocheck/trunk . in /data/go/pkg/mod/cache/vcs/f46ce2ae80d31f9b0a29099baa203e3b6d269dace4e5357a2cf74bd109e13339: exec: "bzr": executable file not found in $PATH
go: labix.org/v2/mgo@v0.0.0-20140701140051-000000000287: bzr branch --use-existing-dir https://launchpad.net/mgo/v2 . in /data/go/pkg/mod/cache/vcs/ca61c737a32b1e09a0919e15375f9c2b6aa09860cc097f1333b3c3d29e040ea8: exec: "bzr": executable file not found in $PATH
go: error loading module requirements

The cause of this is we have a dependency on github.com/influxdata/platform which has a dependency in its go.mod file of launchpad.net/gocheck and labix.org/v2/mgo however neither packages are reference by github.com/influxdata/platform

This means that both go get and go mod vendor when run with module support incorrectly assume that intermediate go.mod files are valid.

Even worse is a matching replace in the local go.mod doesn’t apply and hence can not be used to override the 3rd party dependency.

This means that the failure of a 3rd party to update their go.mod can prevents any dependent projects from downloading / updating.

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 16 (16 by maintainers)

Most upvoted comments

The solution currently on the roadmap is to provide a module proxy that can cache and serve go.mod files, so most users will be able to fetch those directly from the proxy (via HTTPS) rather than installing more esoteric tools (like bzr) or relying on origin servers that may or may not be reliable.

We’re certainly keeping an eye on issues surrounding test dependencies, but at the moment we do not plan to separate test (or tool) dependencies from other general module dependencies.

bcmills on Jan 24, 2019