cmd/go: "go get ...@master" fails when "go install" succeeds

[mattmoor]

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

$ go version
go version go1.14.7 darwin/amd64

Does this issue reproduce with the latest release?

Not sure

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/mattmoor/Library/Caches/go-build"
GOENV="/Users/mattmoor/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/mattmoor/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.14.7/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.14.7/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
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/65/8684yy454bj174jls4gw3tsr0000gp/T/go-build758578442=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

GO111MODULE=on go get github.com/google/ko/cmd/ko@master

What did you expect to see?

I expected things to pass and use k8s.io/[email protected] as constrained in go.mod

What did you see instead?

go: found github.com/google/ko/cmd/ko in github.com/google/ko v0.5.3-0.20200904170505-1e05e91f92a6
# k8s.io/client-go/tools/clientcmd
../../../pkg/mod/k8s.io/[email protected]/tools/clientcmd/validation.go:73:5: cannot use errConfigurationInvalid literal (type errConfigurationInvalid) as type "k8s.io/apimachinery/pkg/util/errors".Aggregate in assignment:
        errConfigurationInvalid does not implement "k8s.io/apimachinery/pkg/util/errors".Aggregate (missing Is method)

---

Some additional details:

• Cloning the repo and go installing at the exact commit pulled by go get WORKS
• I believe that merging this PR fixes things: Fix k8s.io/cli-runtime "require" ko-build/ko#189

[ianlancetaylor]

CC @bcmills @jayconrod

[dmitshur]

The go command is working as intended as far as I can tell. Doing go get github.com/google/ko/cmd/ko@master causes it to try to install a different version, which has a build error.

I expected things to pass and use k8s.io/[email protected] as constrained in go.mod

Constraints in go.mod declare the minimum acceptable version, but a higher version may be selected by the minimum version selection algorithm. There is more detail at https://golang.org/ref/mod#minimal-version-selection. Also see #40784 (comment).

[mattmoor]

Constraints in go.mod declare the minimum acceptable version

AIUI this is true for require, but not replace. I would expect the Go tool to use exactly the version specified by replace and that's what it is disregarding.

When I say "constrained" this is roughly the state of the pertinent constraints in go.mod:

require (
    k8s.io/cli-runtime v0.17.1   # Changing this to match below fixes the "go get" problem.
)

replace (
   k8s.io/cli-runtime => k8s.io/cli-runtime v0.18.8	
)

[dmitshur]

AIUI this is true for require, but not replace. I would expect the Go tool to use exactly the version specified by replace and that's what it is disregarding.

Ah, that is true. I mistakenly thought you were talking about require directive only.

The replace (and exclude) directives in a go.mod file apply only when that module is the main module. The main module is determined by the working directory where you run the go command. Can you clarify what directory you ran the go get command from?

[mattmoor]

I was specifically running it up a directory (cd ..) from any of the repos I normally deal with to avoid the go.mod causing trouble.

[jayconrod]

This is working as designed, but the design is admittedly awkward. We're working on this in #40276. The behavior of replace when installing executables was discussed extensively there and in #30515, so I'll close this issue.

go install currently operates in the context of the module where it's run (the main module), so it applies replace directives from there, not from the module providing the package being installed.

go get may be used in several ways (pretty overloaded). When run within a module, it applies replace directives from that module, not the module providing the package being installed, same as go install.

When go get is run in module mode outside of any module, it does not apply any replace directives.

We're planning to add new functionality to go install, which would let you install an executable in module mode, ignoring the module in the working directory (if any). That would be spelled go install pkg@version.

Notably, go install pkg@version will report an error if the module providing the package has replace directives. We want it to be pretty strict, so there's no ambiguity about what versions of dependencies are used.