cmd/go: module replacements have confusing (lack of) aliasing for package-level state

[bcmills]

If I replace two different modules with the same replacement (say, because I'm planning to merge a fork back into the original package), I expect the two import paths to actually refer to the same package, including the same package state.

However, that is currently not the case: instead, the program receives two distinct copies of the module that do not share state.

(It may be that my expectations are off, but if so, we should clarify the documentation.)

$ go version
go version devel +5f5402b723 Tue Jul 24 23:54:08 2018 +0000 linux/amd64

$ cat go.mod
module example.com/replace

require (
        example.com/a v0.0.0
        example.com/b v0.0.0
)

replace (
        example.com/a => ./p
        example.com/b => ./p
)

$ cat p/p.go
package p

var Global string = "p"

$ cat replace.go
package main

import (
        "fmt"

        a "example.com/a"
        b "example.com/b"
)

func main() {
        a.Global = "a"
        fmt.Println(b.Global)
}

$ go build .

$ ./replace
p

CC: @rsc @myitcv

[bcmills]

Per in-person discussion with @rsc, perhaps for now we should require that the go.mod for the replacement module must declare the same path as the module it is replacing. That supports local forks (the overwhelmingly common use-case for replacements) without committing to any other particular aliasing behavior.

[bcmills]

Or, as another alternative, perhaps we should enforce that paths found in replace directives are unique: you can replace any module with any other module or path, but you can't also require the replacement by its original name.

[gopherbot]

Change https://golang.org/cl/126156 mentions this issue: cmd/go: forbid use of one module with two different paths