cmd/go: can use invalid sub-dependency version

[gucio321]

Go version

go version go1.23.1 linux/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/me/.cache/go-build'
GOENV='/home/me/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/me/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/me/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.1'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/me/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build140071008=/tmp/go-build -gno-record-gcc-switches'

What did you do?

I've created the following project

• Module X uses Module Y at version A
• My project use module X and Module Y at version B
• Version B is newer than version A
• both A and B are not stable versions (my code is not tagged yet as it is in-development yet)
• Version B is not backward compatible with version A ofc and vice-versa

Steps to reproduce

I'm a bit lazy so I'll not create a gh repo with the demo but I'll provide steps to reproduce my situation

cd /tmp/
mkdir testrepo
cd testrepo
go mod init example.com
go get github.com/AllenDang/[email protected] // my Module X (using Module Y at version A)
go get github.com/AllenDang/cimgui-go@5457515 // my Module Y at version B

then, put this code in main.go

package main

import (
	imgui "github.com/AllenDang/cimgui-go"
	"github.com/AllenDang/giu"
)

func main() {
	giu.NewMasterWindow("window", 800, 600, 0)
	imgui.CurrentIO()
}

and run go build .
if you do go get -u github.com/AllenDang/cimgui-go@9ebf619d1d03 it will build correctly

What did you see happen?

It seems that go decided to force Module X use Module Y at version B what resultet in build failure.

What did you expect to see?

if version is v0.* go should handle each commit as another version and respect go.mod require directive correctly.

[gabyhelp]

Related Issues and Documentation

• cmd/go: go.mod can not lock indirect dependencies version #40784 (closed)
• cmd/go: dependency module in workspace has go version requirement loaded before local replacement #66516
• cmd/go: downgrading a module with `go get` retains indirect dependencies #26481 (closed)
• cmd/go: v2 module in sub-sub-directory cannot be found #38592 (closed)
• cmd/go: unable to build with v2+ of same module in GOPATH environment #28937 (closed)
• cmd/go: can't get mod by version "vx.x" #27528 (closed)
• cmd/go: modules not keeping downgraded version of dependency #34794 (closed)
• cmd/go: bad error message when using `vendor` directory while specifying too old Go version #67587 (closed)
• cmd/go: add (or make explicit) tests for ambiguous imports in module mode #28806
• cmd/go: project depending on project using modules not building: "error loading module requirements" #31929 (closed)

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

[seankhliao]

this is working as intended, each unique import path can only exist at a single version, we're not going to allow the confusion of having the same name mean different things

[gucio321]

ok, sounds reasonable.

[gucio321]

@seankhliao I just tought about this issue a little bit more and now it doesn't seem so clear to me.

Lets take a look at the following example:

• Module Y added a function called Foo and was tagged as v0.1.0
• then, function Foo was renamed as Bar and this change was tagged v0.2.0
• lets note that according to Semantic Versioning Module Y was allowed to do this as v0.* is dev version and it has no backward compatibility
• now Module X uses v0.1.0 and uses Foo()
• now Module Z imports Module X and (also) imports Module Y but with version v0.2.0
  (sorry, if I'm repeating the OP but I just wanted to add more details to my example).

I think that everyone should agree that this setup should work, because why it shouldn't?

we're not going to allow the confusion of having the same name mean different things

My answer is, that import paths are determined in module's go.mod file, this is what are go.mos for, right? So I see no reason why import paths should not change meaning in the area of certain module.