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.

Sign up for GitHub

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

Jump to bottom

cmd/go: clarify case of incompatible replace directives #32123

Closed
estroz opened this issue May 17, 2019 · 3 comments
Closed

cmd/go: clarify case of incompatible replace directives #32123

estroz opened this issue May 17, 2019 · 3 comments
Labels
FrozenDueToAge

Comments

@estroz
Copy link

estroz commented May 17, 2019

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

$ go version
go version go1.12.1 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
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/user/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/user/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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-build236859032=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Scenario:

  1. parent, child, and somedep are all go modules.
  2. parent depends on child; it has require child v0.1.0 in its go.mod.
  3. child release v0.1.0 depends on somedep; it has require somedep master and replace somedep => somedep v0.2.0 in its go.mod.
    • somedep’s latest release is v0.3.0, and master is a few commits beyond that.
  4. parent also depends on somedep; it has require somedep master but no replace for somedep.

A few questions that need clarification:

  1. What version of somedep will be resolved when go build is run in parent?
  2. Will the replace line in child's go.mod override parent's require?
  3. What happens if parent has no require somedep master (no direct dependency on somedep) in its go.mod, all else the same as in the above scenario?
  4. What happens if parent has replace somedep => somedep v0.3.0 in its go.mod, all else the same as in the above scenario?

If these questions can be answered by documentation, please point me in the right direction. Thanks!

What did you expect to see?

Not sure.

What did you see instead?
@bcmills
Copy link
Contributor

bcmills commented May 20, 2019

  1. require somedep master within child's go.mod file should be an error, since that is a branch name rather than a canonical version. (Best case, it might resolve to a //indirect dependency within parent, but I don't think that even that makes sense in terms of build reproducibility.)

(If you find that is not the case, please file an issue.)

  1. As documented, “Exclude and replace apply only in the main module's go.mod and are ignored in dependencies.”

  2. The version selected for the main module is the minimal version that satisfies the requirements of its (transitive) dependencies.

  3. A replace directive in the main module replaces the source code for the named module with the source code found at the named replacement location. (That is not always what you want, but it's what we've implemented so far: see cmd/go: allow replacement modules to alias other active modules #26904.)

@bcmills bcmills closed this as completed May 20, 2019
@estroz
Copy link
Author

estroz commented May 20, 2019

@bcmills by master I meant the latest commit in master, which will be resolved to a (pseudo-)version by go. I should have specified that in the issue text.

Your answers helped a lot, thank you.

@bcmills
Copy link
Contributor

bcmills commented May 20, 2019

Assuming that the go command derives them correctly (see #27171), pseudo-versions sort in between the nearby tagged versions using the usual semantic-version comparisons.

@golang golang locked and limited conversation to collaborators May 19, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ALTree @bcmills @gopherbot @estroz