cmd/go: go.work: `go build` requires versioned replace directive when replacing a used module with a local path

[mlaventure]

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

$ go version
go version go1.18.5 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/mlaventure/.cache/go-build"
GOENV="/home/mlaventure/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/mlaventure/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/mlaventure/go"
GOPRIVATE=""
GOPROXY="direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18.5"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/mlaventure/tmp/go/workspace/realdeal/go.mod"
GOWORK="/home/mlaventure/tmp/go/workspace/go.work"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2178506260=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Given the following workspace structure:

~/tmp/go/workspace $ tree
.
├── fubar
│   ├── fubar.go
│   └── go.mod
├── go.work
└── realdeal
    ├── go.mod
    ├── realdeal
    └── realdeal.go

2 directories, 6 files

With the following go.work:

~/tmp/go/workspace $ cat go.work 
go 1.18

use ./fubar
use ./realdeal

replace github.com/foo/fubar   => ./fubar

Build realdeal which depends on fubar:

~/tmp/go/workspace/realdeal $ go build .

What did you expect to see?

Nothing, the build should succeed

What did you see instead?

go: workspace module github.com/foo/fubar is replaced at all versions in the go.work file. To fix, remove the replacement from the go.work file or specify the version at which to replace the module.

Found workaround

The only way I've found to fix this is to update the go.work to be as follow:

~/tmp/go/workspace $ cat go.work 
go 1.18

use ./fubar
use ./realdeal

replace github.com/foo/fubar v0.0.0-00010101000000-000000000000 => ./fubar

This is not needed if a workspace is not used. It also seems to contradict the example from the documentation (https://go.dev/ref/mod#workspaces):

replace (
    golang.org/x/net v1.2.3 => example.com/fork/net v1.4.5
    golang.org/x/net => example.com/fork/net v1.4.5
    golang.org/x/net v1.2.3 => ./fork/net
    golang.org/x/net => ./fork/net
)

[dmitshur]

CC @bcmills, @matloob.

[BourgeoisBear]

workspace replace lines also cause problems with go mod tidy

go: downloading mydomain.com/module v0.0.0-00010101000000-000000000000
github.com/acct/testcmd imports
        mydomain.com/module: unrecognized import path "mydomain.com/module": https fetch: Get "https://mydomain.com/module?go-get=1": ...

[wangmir]

@dmitshur @bcmills Is there any progress in this? I also have similar problem, when I trying to migrate existing project to use go workspace. It seems replace in go.work is not available to me too. I cannot run go mod tidy

[intel352]

Same problem for me.
I presume this could be getting caused by the fact that I'm specifying the same local module in the use directive as in the replace directive, which I suspect is not intended behavior, but considering Go keeps trying to remotely fetch workspace modules during build rather than respecting the go.work, I was hoping the replace would solve the situation.

Frankly I'm surprised, most of the go tooling is generally high quality, but go.work seems quite error prone...

[bcmills]

In general we would expect modules that are included in a workspace to not also require a replace directive in the go.work file. Can you explain more about the circumstance that led you to that arrangement?

[sudo-bmitch]

The reason I was looking to do this was to handle an environment where I cannot directly connect to the upstream git repo. I'm seeing go execute git ls-remote -q origin ... (which fails in my environment) for the modules referenced with use but not with replace.

I can remove the use and only have a replace, which works, but only for libraries where I'm not running a go build.

[theaog]

don't know where you came up w/ that long versioning string, fyi: v0.0.0 also works to satisfy go work complaints.

use ./cmd/fubar
replace github.com/foo/fubar v0.0.0 => ./cmd/fubar

to note that you shouldn't need the replace directive when in a workspace managed by go.work. it should automatically resolve your remote module github.com/foo/fubar to the local version available at ./cmd/fubar.

[sudo-bmitch]

it should automatically resolve your remote module github.com/foo/fubar to the local version available at ./cmd/fubar.

It appears to do that by running git ls-remote -q origin ... which requires access to the remote git server.

[wangmir]

@bcmills Please check this issue. I think it's related.

#50750

go.work should support replace, when we think about monorepo situation. Placing replace on all of the modules of microservices in a monorepo is not ideal case i think.

[independentid]

I am having the same problems in 1.19. Once I put in go.work everything goes haywire.

• Replace works in go.mod but can cause problems elsewhere in the workspace (Goland Issues suggestions to create a workspace)
• go.work - using use block causes go work sync to issue errors about missing versions for modules in the use clause. Using the long version number, a new number, or using v.0.0.0 will still generate the same errors
• Replace in go.work sort of solves some problems but the versioning issue remains if any module is an indirect requirement in another module.

Thinking about trying the latest go to see if the behavior changes.