cmd/go: install: respect replace directive if the replaced module is in the same repository

[metakeule]

Go version

go 1.23.0

Output of go env in your module/workspace:

set GO111MODULE=on
set GOARCH=amd64
set GOEXE=.exe
set GOEXPERIMENT=loopvar
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\xxxx\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLCHAIN=local
set GOVCS=
set GOVERSION=go1.23.0
set GODEBUG=
set GCCGO=gccgo
set GOAMD64=v1

What did you do?

go install gitlab.com/metakeule/cmdlibprob1@v0.0.2

go install gitlab.com/metakeule/cmdlibprob2/cmd/cmdlibprob2@v0.0.1

go install gitlab.com/metakeule/cmdlibprob3/cmd/cmdlibprob3@v0.0.1

What did you see happen?

go install gitlab.com/metakeule/cmdlibprob1@v0.0.2
go: downloading gitlab.com/metakeule/cmdlibprob1 v0.0.2
go: gitlab.com/metakeule/cmdlibprob1@v0.0.2 (in gitlab.com/metakeule/cmdlibprob1@v0.0.2):
        The go.mod file for the module providing named packages contains one or
        more replace directives. It must not contain directives that would cause
        it to be interpreted differently than if it were the main module.

go install gitlab.com/metakeule/cmdlibprob2/cmd/cmdlibprob2@v0.0.1
go: downloading gitlab.com/metakeule/cmdlibprob2 v0.0.1
go: gitlab.com/metakeule/cmdlibprob2/cmd/cmdlibprob2@v0.0.1: module gitlab.com/metakeule/cmdlibprob2@v0.0.1 found, but does not contain package gitlab.com/metakeule/cmdlibprob2/cmd/cmdlibprob2

go install gitlab.com/metakeule/cmdlibprob3/cmd/cmdlibprob3@v0.0.1
go: downloading gitlab.com/metakeule/cmdlibprob3 v0.0.1
go: gitlab.com/metakeule/cmdlibprob3/cmd/cmdlibprob3@v0.0.1: module gitlab.com/metakeule/cmdlibprob3@v0.0.1 found, but does not contain package gitlab.com/metakeule/cmdlibprob3/cmd/cmdlibprob3

What did you expect to see?

nothing, it should just install

Context

We have a repository with a library and a command that uses the library. This is pretty common and was never a problem in the pre go modules era.

This allows in principle for a library and a command to be released in sync with the same version number and the same behaviour.

An additional reasonable requirement is, that the command should be able to have more dependencies than the library. And therefor the library and the command are two different go modules (each has its own go.mod file with its own path).

In our case, there are other libraries depending on the library. These other libraries are used by the command. This is not possible without having two separate go modules in this repository.

I have set up three repositories to reflect the three different strategies for combining a command and a library here:

• https://gitlab.com/metakeule/cmdlibprob1
• https://gitlab.com/metakeule/cmdlibprob2
• https://gitlab.com/metakeule/cmdlibprob3

The problem is, that without a replace directive inside the go.mod file of the command, there is no way to release the command and the library at the same time, because the command depending on the library needs to find it first.

However, having a replace directive, even if it is pointing to the same repository, is not supported by go install yet (see above).

Changing this would help a lot and I can't see a reason, why it should not be supported in this case, because the repository needs to be downloaded anyway to compile.

As it is, we need to make double releases all the time: first for the library and then for the command. But before the release of the command we first need to update the version of the library that the command depends on, although it is in the same repo! This is error prone, unnecessary work and confusing for the users, since the same version of library and command might behave differently.

Maybe this should be changed to be a proposal, since another request was closed as "works as intended". But I would say, that this is a very reasonable and useful request with minimal implementation impact.

So it is not about allowing replace directives in general to be used by go install, but only in the very specific case, when:

• the original path of the module that is to be replaced is within the same repository
• the target path is relative and in such a way that it is reachable within the repository

Example

module gitlab.com/metakeule/cmdlibprob3/cmd/cmdlibprob3
replace gitlab.com/metakeule/cmdlibprob3/lib/cmdlibprob3 => ../../lib/cmdlibprob3

would be valid

module gitlab.com/metakeule/cmdlibprob3/cmd/cmdlibprob3
replace gitlab.com/metakeule/cmdlibprob3/lib/cmdlibprob3 => ../../../lib/cmdlibprob3

would not be valid.

From resolving the paths it is actually very easy to check, that

from gitlab.com/metakeule/cmdlibprob3/cmd/cmdlibprob3
to ../../lib/cmdlibprob3 is resulting in gitlab.com/metakeule/cmdlibprob3/lib/cmdlibprob3 so this, is exacly the same as the original path and should be allowed.

go.sum Problem

Tagging both versions at the same time is possible. But the go.sum file of the dependant package is always one commit behind.

[gabyhelp]

Related Issues and Documentation

• cmd/go: go install cmd@version errors out when module with main package has replace directive #44840 (closed)
• Go module replace doesn't work when 2 levels deep #35450 (closed)
• cmd/go: Unable to update dependency using insteadOf #34148 (closed)
• x/tools/cmd/gorename: go install with error: module providing named packages contains one or more replace directives #69548 (closed)
• x/tools/gopls: do not include replace directive in release versions #42627 (closed)
• cmd/go: install fails when installing old releases of GH transferred repositories. #60452 (closed)
• cmd/go: "no required module provides package" error with file path to replacement module inside another replacement #43806
• cmd/go: get fails to get a package when mod file has replace in a repo that imports packages from another go module in the same repository #35693 (closed)
• cmd/go: `replace` directive for go modules does not work recursively #38665 (closed)
• cmd/go: GO111MODULE=on go get -v -insecure gitlab.com/xxx/xxx failed #32569 (closed)

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

[metakeule]

Before considering closing this request, like #44840 and #40276 please answer the question, how a repo can be organized in a way that allows the above behavior with the way go install currently works. It is not (only) about replace directives and go install, but about being able to have a repo with two modules where one uses the other and they can be released together.

[mknyszek]

CC @matloob @samthanawalla

[metakeule]

It is obviously for using go install outside of a go module. For end users.

[seankhliao]

Duplicate of #50698

there's no reason why you can't tag and update both in the same commit.

[metakeule]

Duplicate of #50698

there's no reason why you can't tag and update both in the same commit.

Yes, there is a reason: The dependent can only get the correct go.sum entry when the repo is tagged and pushed. So when tagging in the same commit, the go.sum would be outdated.

[metakeule]

Duplicate of #50698

Since there the go.sum problem was not mentioned, can you please reopen this issue?