cmd/go: reject the `-modfile` flag in workspace mode

[ZekeLu]

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. And reproduce on gotip too.

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

go env

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/zeke/.cache/go-build"
GOENV="/home/zeke/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/zeke/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/zeke/go"
GOPRIVATE=""
GOPROXY="https://goproxy.cn,direct"
GOROOT="/snap/go/current"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/snap/go/current/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="/home/zeke/src/temp/76174480/go.work"
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-build2566520163=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I run go run with the -modfile flag in a workspace:

$ go run -modfile ./m1/go.mod ./m1

directory structure and files

``` ├── go.work ├── m1 │   ├── go.mod │   └── main.go └── m2 ├── go.mod └── main.go ``` **go.work**: ``` go 1.20 use ( ./m1 ./m2 ) ``` **m1/go.mod**: ``` module example.com/m1 go 1.20 ``` **m1/main.go**: ```go package main import "fmt" func main() { fmt.Println("Hello m1") } ``` **m2/go.mod**: ``` module example.com/m2 go 1.20 ``` **m2/main.go**: ```go package main import "fmt" func main() { fmt.Println("Hello m2") } ```

What did you expect to see?

It runs the program or displays more friendly error message.

What did you see instead?

go: module example.com/m1 appears multiple times in workspace

What's wrong?

https://github.com/golang/go/blob/2fd8c5b2d80809040e348a431ff292efbeb6e82c/src/cmd/go/internal/modload/init.go#L530-L535

When -modfile is specified, the func modFilePath ignores the parameter modRoot and returns the specified mod file stored in cfg.ModFile directly. This is incorrect in workspace mode when there are multiple mod roots (specified by the use directive) because all the mod roots will be resolved to the same go.mod file.

https://github.com/golang/go/blob/2fd8c5b2d80809040e348a431ff292efbeb6e82c/src/cmd/go/internal/modload/init.go#L730-L731

I would like to work on this issue. But I'm not sure what should we do about it. The most simple fix is to prevent the -modfile flag in workspace mode. Opinions?

[seankhliao]

is this worth fixing over using go run -C ./m1 .?

[ZekeLu]

This issue is forked from this stackoverflow question. I don't use it myself. I don't understand why the OP wants to specify the -modfile flag yet. I will copy your suggestion there. Thank you!

Update: In fact, it works without the -modfile flag. Don't need to apply the -C flag.

[bcmills]

What did you expect to see?

It runs the program or displays more friendly error message.

Thanks for the report! I agree that a clearer error message would be good to have here. (CC @matloob)

[gopherbot]

Change https://go.dev/cl/493315 mentions this issue: cmd/go/internal/modload: reject the -modfile flag in workspace mode

[ZekeLu]

I don't understand why the OP wants to specify the -modfile flag yet.

This is clear now. The OP found that one of his module is built with an unexpected third-party module due to the minimal version selection (MVS) in workspace, and he tried to workaround it with the -modfile flag. Now he understand how MVS works, and there is not need for the -modfile flag (or anything else) now.