CODEWITHSUNDEEP
gogo-modules
aj3423
aj3423

Reputation: 2581

Avoid writing "replace" for recursive dependency for local modules

I'm trying to switch from GOPATH to Go Module. I have many local modules that used by many executable, I can't put them online for security reason.

When module "d" depends on three packages: "a", "b", "c", I need to "replace" in go.mod:

replace m.y/a => /my/a
replace m.y/b => /my/b
replace m.y/c => /my/c

When an executable imports package "d", it doesn't import a/b/c directly, but it still requires the "replace a,b,c" in the go.mod:

replace m.y/a => /my/a
replace m.y/b => /my/b
replace m.y/c => /my/c

replace m.y/d => /my/d

Is it by design or I'm using it wrong? Since a/b/c is already in d's go.mod, why do I have to write them again for every executable that using d?

Does go module support import from another go.mod? Or is it possible to not write "replace a/b/c" again and again ?

Upvotes: 2

Views: 2545

Answers (2)

bcmills
bcmills

Reputation: 5197

This is by design. Per https://golang.org/ref/mod#go-mod-file-replace:

replace directives only apply in the main module's go.mod file and are ignored in other modules. See Minimal version selection for details.

If you have a set of packages that are tightly coupled and cannot be published even on a local or private server, then they should probably be part of a single module (module m.y) instead of split into separate ones (module m.y/a, module m.y/b, etc.).

On the other hand, if you can publish them on a private server, then you can use a .netrc file to provide credentials to the go command, and the GOPRIVATE environment variable to instruct it not to look for checksums in the public checksum database. See https://golang.org/ref/mod#private-modules for more detail.

Upvotes: 1

Hymns For Disco
Hymns For Disco

Reputation: 8405

replace shouldn't be used to fix your source code. It's used to fix your build configuration, usually temporarily or for the development environment only.

If the import strings for your packages have permanently changed, you need to update the source code that imports them. This is one reason why you want to avoid renaming packages or modules.

Upvotes: 3

Related Questions