同一项目中的多个模块

Question

我一直在玩 Go 模块，我想知道以下目录结构的最佳实践是什么：project├── go.mod├── main.go└── players    ├── go.mod    ├── players.go    └── players_test.goplayers一开始我在将包导入我的根项目时遇到问题，但我注意到我可以在根go.mod文件中执行此操作module github.com/<name>/<project>require (    github.com/<name>/players v0.0.0)replace github.com/<name>/players => ./playersimport "github.com/<name>/players"这让我可以在我的文件中做main.go。现在这种方法有效并且是从这里获取的，但我不确定这是否是正确的方法，或者这种方法是否只是为了在版本控制之外临时更新本地包。另一种选择，似乎有点矫枉过正，是让每个模块都有自己的存储库？长话短说，- 在同一个存储库中拥有多个模块并将它们导入其他模块/根main.go文件的最佳实践方法是什么？

Answer 1

一般来说，模块应该是包的集合。

但是您仍然可以创建单个包的模块。这可能只有在您希望这些包具有不同的生命周期时才有意义。当您想从另一个项目导入这些模块并且不希望整个包集合的开销时，它也可能有意义。

一般来说：

模块是相关的 Go 包的集合，它们作为一个单元一起进行版本控制。

模块记录精确的依赖需求并创建可重现的构建。

大多数情况下，版本控制存储库只包含一个在存储库根目录中定义的模块。（单个存储库支持多个模块，但通常这会比每个存储库一个模块导致更多的持续工作）。

总结存储库、模块和包之间的关系：

1. 一个存储库包含一个或多个 Go 模块。2.每个模块包含一个或多个Go包。3. 每个包由一个或多个 Go 源文件组成，位于一个目录中。

Answer 2

我知道这是一个老问题，但是在一个存储库中管理多个模块时，有一些更多的细节值得一提，无论有没有go.work.

长话短说

每种方法都有利有弊，但如果您正在处理包含许多模块的大型代码库，我建议坚持使用基于提交或标签的版本处理，并使用 Go Workspace 进行日常开发。

转到模块详细信息

replace没有版本控制的指令

当你使用replace指向本地目录的指令时，你会发现依赖模块的版本为v0.0.0-00010101000000-000000000000. 基本上你得不到版本信息。

使用模块路径go.mod定义的主要模块无法进行可重现的构建，因为指令的依赖目标可能已更新其内容。如果许多模块使用的依赖目标，这可能会特别成问题。这种通用包中的任何更改都可能同时导致所有依赖项的行为更改。github.com/name/projectgithub.com/name/projectreplacegithub.com/name/project/players

如果那不是您关心的问题，replace指令应该绝对可以正常工作。在这样的设置中，go.work可能是您并不真正需要的层。

有版本控制

如果您想确保版本设置适用于多个模块的可重现和确定性构建，您可以采用几种不同的方法。

一go.mod，一个存储库

这可能是最简单的方法。对于每个模块，都有清晰的提交历史记录和版本控制。只要您通过远程存储库引用模块，这可能是最简单的设置，并且依赖设置非常清晰。

但是，请注意，这种方法意味着您需要管理多个存储库，并且提供go.work帮助将需要适当的本地目录映射，这对于代码库的新手来说可能很困难。

基于提交的版本控制

仍然可以使用版本信息确定性地定义依赖关系，以便您可以在单个存储库中构建代码。基于提交的方法需要最少的步骤，并且仍然可以很好地工作。不过，有一些问题需要注意。

• 要github.com/name/project对 具有依赖性github.com/name/project/players，您需要确保所需的代码在远程存储库中。这是因为github.com/name/project将从远程存储库中提取代码和提交信息，即使存储库的本地副本上有相同的代码也是如此。这确保了从提交引用中获取的版本github.com/name/project/players，例如v0.1.1-0.20220418015705-5f504416395d(ref: details of "pseudo-version" )

• 模块名称必须与目录结构匹配。例如，如果您有单个存储库github.com/name/project和模块/src/mymodule/，则模块名称必须是github.com/name/project/src/mymodule。这是因为当模块路径解析发生时，Go 会找到存储库的根目录（在上面的示例中，这将是github.com/name/project.git），然后尝试根据模块名称跟踪目录路径。

• 如果您在私有存储库中工作，则需要确保go.sum检查不会阻止您。您可以简单地使用GOPRIVATE=github.com/name/project来指定您不希望跳过校验和验证的路径。

基于标签的版本控制

除了使用提交 SHA，您还可以使用 Git 标签。

但是因为一个存储库中可能有很多模块，Go Module 需要找到哪个标签映射到哪个。例如，具有以下目录结构：

# All assumed to be using `github.com/name/project` prefix before package name

mypackage/          # v1.0.0

anotherpackage/     # v0.5.1

nested/dependency/  # v0.8.3

您将需要在 中创建标签github.com/name/project，其名称与目录结构完全匹配，例如：

mypackage/v1.0.0

anotherpackage/v0.5.1

nested/dependency/v0.8.3

这样，每个标签都被 Go Module 正确引用，并且您的依赖关系可以保持确定性。

go.work行为

如果您go.work在父目录上有go work use github.com/name/project/players等，则优先使用本地文件。即使您在go.mod.

对于跨多个项目的本地开发，Go Workspace 是一种同时处理多个事物的好方法，而无需先推送依赖项的代码更改。但与此同时，实际发布仍然需要分解提交，以便稍后在其他代码更改中引用第一次提交。

go.work据说是您很少需要提交到存储库的文件。不过，您必须了解在父路径中具有的影响go.work。