build: tools with dependency conflicts cannot be built

[anuraaga]

Go version

go version devel go1.24-39f2032c

Output of go env in your module/workspace:

AR='ar'
CC='clang'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='clang++'
GCCGO='gccgo'
GO111MODULE=''
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/Users/anuraag/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/anuraag/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/vx/38td0k79201f9zn_myzbqx_40000gn/T/go-build3209673573=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/Users/anuraag/git/hellotools/go.mod'
GOMODCACHE='/Users/anuraag/go/pkg/mod'
GONOPROXY='github.com/tetrateio/*'
GONOSUMDB='github.com/tetrateio/*'
GOOS='darwin'
GOPATH='/Users/anuraag/go'
GOPRIVATE='github.com/tetrateio/*'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/Users/anuraag/sdk/gotip'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/anuraag/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/Users/anuraag/sdk/gotip/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='devel go1.24-39f2032c Tue Jan 7 20:05:28 2025 -0800'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

https://github.com/anuraaga/hellotools

Add tool dependency on two tools which depend on different versions of the same library, which has an API break in between versions. Because tool dependencies are tracked monolithically in go.mod, it only references the newer version and the tool depending on the older version cannot be built.

When initially using the tools.go pattern back in the day, I had to give up on it for this reason and stick to go run foo@ver in build scripts to avoid conflicts between them. Ideally with tool now a native feature of Go, it could be smarter than collapsing all the dependencies into one, but admittedly this will probably be a large change needing a proposal for something like namespace'd require. Until it though, I'm nervous to try using tool since I may need to migrate back to go run. Ideally v0 libraries aren't used in the wild, but in practice especially in CLIs I find they're common.

Just random idea

tool (
    github.com/anuraaga/printgoodbye
    github.com/anuraaga/printhello
)

// Standard dependencies
require (
    ...
)

require for github.com/anuraaga/printgoodbye (
    github.com/anuraaga/printgoodbye v0.0.0-20250109050137-9fc00af898b6 // indirect
    github.com/anuraaga/goprint v0.0.0-20250109045802-8df2b2614142 // indirect
)

require for github.com/anuraaga/printhello (
    github.com/anuraaga/printhello v0.0.0-20250109050002-47d5b1f53d43 // indirect
    github.com/anuraaga/goprint v0.0.0-20250109045748-10bfc35026a3
)

What did you see happen?

❯ gotip tool printhello
# github.com/anuraaga/printhello
../../go/pkg/mod/github.com/anuraaga/printhello@v0.0.0-20250109050002-47d5b1f53d43/main.go:6:10: undefined: goprint.Print

What did you expect to see?

Tool builds and runs

[gabyhelp]

Related Issues

• x/tools/gopls: make go.mod diagnostics on mismatched requirements available when go.work is used #48920
• golang.org/x/tools/gopls declares a broken dependency on golang.org/x/tools@v0.14.1 #64995 (closed)
• x/tools/gopls: imports older modules #67345
• cmd/go: Setting up a go workspace breaks building #57738 (closed)
• x/tools/gopls: references doesn't work properly. #60676 (closed)
• x/tools/gopls: Implement action should ignore importing the current package #61830 (closed)
• cmd/go: can use invalid sub-dependency version #69437 (closed)
• x/tools/gopls: negated build flag causes error #59346
• cmd/go: internal error in `go work sync` #65363
• cmd/compile: unexpected error about conflicting package heights #25568 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[seankhliao]

See the long discussion in #48429, it was an explicit decision to do this.

[anuraaga]

@seankhliao I did read through the long discussion and saw a comparison of current scheme (one version per dependency) and one of not tracking any dependencies (security issue). Was it discussed to track separately like the proposal? I couldn't find it.

At the bare minimum, there is still a bug then that go get -tool will add dependencies that can't actually be built, if it's going to fail it should be when running go get and seeing a version conflict.

Edit: or even more of a really bare minimum, the potential trap needs to be documented.

[seankhliao]

it is the same as adding any other dependency. see #48429 (comment)

[anuraaga]

I see - given CLI tools have not had to worry about potential API conflicts like this, it is disappointing to see an after-the-fact change where their users may see this breakage using a native Go feature (tools.go was basically a workaround), and that it is as intended. It's particularly sad since it's the maintainers that are going to be the ones that foot the bug reports about compilation failures. But the clarity helps - for my tools, I will go ahead and preface the readmes with go tool being an unsupported configuration.