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

Jump to bottom

go.mod replace is not heritable #39310

Closed
enuoCM opened this issue May 29, 2020 · 2 comments
Closed

go.mod replace is not heritable #39310

enuoCM opened this issue May 29, 2020 · 2 comments
Labels
FrozenDueToAge

Comments

@enuoCM
Copy link

enuoCM commented May 29, 2020

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

go1.14.3 darwin/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output
GO111MODULE="on"
GOARCH="amd64"
...
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
...

What did you do?

Project B (latest version is v1.0.0) with mod file:

module github.com/xxx/b

go 1.14

require (
    ...
    github.com/xxx/a v1.2.0
)

replace github.com/xxx/a => github.com/xxx/a-fork v1.2.1

Project C with mod file:

module github.com/xxx/c

go 1.14

require (
    ...
    github.com/xxx/b v1.0.0
)

Build project C, the code of C still references to github.com/xxx/a v1.2.0

What did you expect to see?

The code of C should reference to github.com/xxx/a-fork v1.2.1 instead

What did you see instead?

The code of C references to github.com/xxx/a v1.2.0
@seankhliao
Copy link
Member

working as intended https://github.com/golang/go/wiki/Modules#gomod

exclude and replace directives only operate on the current (“main”) module. exclude and replace directives in modules other than the main module are ignored when building the main module. The replace and exclude statements, therefore, allow the main module complete control over its own build, without also being subject to complete control by dependencies.

@enuoCM
Copy link
Author

enuoCM commented Jun 1, 2020 •
edited

@seankhliao @andybons I see. Thanks. But should this be a drawback? With this, it's hard and unreliable to require other modules which have replace . Even the replace is not ignored, the "main" module can still complete control all dependencies by it's own replace.

@enuoCM enuoCM mentioned this issue Jun 2, 2020
Closed
@golang golang locked and limited conversation to collaborators Jun 2, 2021
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
@andybons @gopherbot @enuoCM @seankhliao