Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
bcmills opened this issue Jul 25, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@bcmills
Copy link
Member

commented Jul 25, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Jul 26, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Jul 26, 2018

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.

@bcmills bcmills self-assigned this Jul 26, 2018

@gopherbot

This comment has been minimized.

Copy link

commented Jul 26, 2018

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

@gopherbot gopherbot closed this in 68170aa Jul 31, 2018

jeet-parekh added a commit to jeet-parekh/go that referenced this issue Jul 31, 2018

cmd/go: forbid use of one module with two different paths
If a single module is imported via two different paths (e.g., as itself and as a
replacement for something else), some users may be surprised if the two paths
do not share the same package-level state. Others may be surprised if the two
paths do share state.

Punt on the question for now by rejecting that condition explicitly.

Fixes golang#26607.

Change-Id: I15c3889f61f8dd4ba5e5c48ca33ad63aeecac04e
Reviewed-on: https://go-review.googlesource.com/126156
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.