英文:
Avoid writing "replace" for recursive dependency for local modules
问题
我正在尝试从GOPATH切换到Go Module。我有很多本地模块，被许多可执行文件使用，出于安全原因，我不能将它们放在线上。
当模块"d"依赖于三个包："a"、"b"、"c"时，我需要在go.mod中进行"replace"操作：
replace m.y/a => /my/a
replace m.y/b => /my/b
replace m.y/c => /my/c
当一个可执行文件导入包"d"时，它并不直接导入a/b/c，但仍然需要在go.mod中写入"replace a,b,c"：
replace m.y/a => /my/a
replace m.y/b => /my/b
replace m.y/c => /my/c
replace m.y/d => /my/d
这是设计上的要求还是我使用方式有误？因为a/b/c已经在d的go.mod中了，为什么我每次使用d的可执行文件时都要再次写入它们？
Go模块是否支持从另一个go.mod导入？或者是否有可能不再反复写入"replace a/b/c"？
英文:
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 ?
答案1
得分: 3
replace 不应该用于修复你的源代码。它用于修复构建配置，通常是临时的或仅用于开发环境。
如果导入包的字符串已经永久更改，你需要更新导入它们的源代码。这是你要避免重命名包或模块的原因之一。
英文:
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.
答案2
得分: 1
这是设计上的考虑。根据 https://golang.org/ref/mod#go-mod-file-replace 的说明：
replace 指令只在主模块的
go.mod文件中生效，在其他模块中会被忽略。有关详细信息，请参阅最小版本选择。
如果你有一组紧密耦合的包，即使在本地或私有服务器上也不能发布，那么它们可能应该是单个模块 (module m.y) 的一部分，而不是拆分为多个模块 (module m.y/a，module m.y/b 等)。
另一方面，如果你可以将它们发布到私有服务器上，那么你可以使用 .netrc 文件为 go 命令提供凭据，并使用 GOPRIVATE 环境变量指示它不要在公共校验和数据库中查找校验和。有关详细信息，请参阅 https://golang.org/ref/mod#private-modules。
英文:
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论