cmd/go: install fails when installing old releases of GH transferred repositories.

[i4ki]

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

$ go version
go version go1.20.4 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/i4k/.cache/go-build"
GOENV="/home/i4k/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/i4k/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/i4k/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20.4"
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 -fdebug-prefix-map=/tmp/go-build3507918026=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I'm not sure if this is a bug but if not I'd like to understand the reasoning.

We have an open-source cmd-line tool with several releases but we created a dedicated Github organization and transferred the repository to it. We planned to update the module name, all import paths and documentation to the new URL.
Then the problem is that:

# old module name
go install github.com/mineiros-io/terramate/cmd/[email protected]

works fine but using the new module name it fails:

$ go install github.com/terramate-io/terramate/cmd/[email protected]
go: github.com/terramate-io/terramate/cmd/[email protected]: github.com/terramate-io/[email protected]: parsing go.mod:
	module declares its path as: github.com/mineiros-io/terramate
	        but was required as: github.com/terramate-io/terramate

GitHub is now redirecting requests from the old repo to the new one, then installing with the old repo still works, but if explicitly using the new name/url then it fails...

In the Go proxy, the new module name can reach all releases created with the old name: https://proxy.golang.org/github.com/terramate-io/terramate/@v/v0.2.18.mod
(Check the module declaration)

And if manually downloading the zip from the proxy, unzipping and then everything works (go install, go build, go test, etc).

So it looks like go install is very picky and disallows the installation if the requested module is different than the one obtained from the released modfile.

Why?

EDIT: I identified the only check that prevents this from working

I just compiled Go from sources and removed this if below and then the install works:

go/src/cmd/go/internal/modload/modfile.go

Lines 634 to 645 in 055c186

	// In theory we should only allow mpath to be unequal to m.Path here if the
	// version that we fetched lacks an explicit go.mod file: if the go.mod file
	// is explicit, then it should match exactly (to ensure that imports of other
	// packages within the module are interpreted correctly). Unfortunately, we
	// can't determine that information from the module proxy protocol: we'll have
	// to leave that validation for when we load actual packages from within the
	// module.
	if mpath := summary.module.Path; mpath != m.Path && mpath != actual.Path {
	return nil, module.VersionError(actual, fmt.Errorf(`parsing go.mod:
	module declares its path as: %s
	but was required as: %s`, mpath, m.Path))
	}

I'd like to know if the comment above the if applies to this case as well (GitHub redirection).

What did you expect to see?

The go install invocations using the new module name should be able to install releases created with the old module name.

What did you see instead?

The go install cannot install releases created before a repository was transferred using the new module name.

[seankhliao]

Duplicate of #50278

[i4ki]

It's not a duplicate... This is not a case of forking a repository.
The proposed solution there involves a -replace option which does not make any sense here, as the old repository doesn't exist anymore.

[seankhliao]

the issue is the same, you want to install a module using a different name than the one it declared in its go.mod file