同一项目中的多个模块

Question

我一直在玩 Go 模块，我想知道以下目录结构的最佳实践是什么：

project

├── go.mod

├── main.go

└── players

    ├── go.mod

    ├── players.go

    └── players_test.go

players一开始我在将包导入我的根项目时遇到问题，但我注意到我可以在根go.mod文件中执行此操作

module github.com/<name>/<project>

require (

    github.com/<name>/players v0.0.0

)

replace github.com/<name>/players => ./players

import "github.com/<name>/players"这让我可以在我的文件中做main.go。

现在这种方法有效并且是从这里获取的，但我不确定这是否是正确的方法，或者这种方法是否只是为了在版本控制之外临时更新本地包。

另一种选择，似乎有点矫枉过正，是让每个模块都有自己的存储库？

长话短说，- 在同一个存储库中拥有多个模块并将它们导入其他模块/根main.go文件的最佳实践方法是什么？

Answer 1

一般来说，模块应该是包的集合。但是您仍然可以创建单个包的模块。这可能只有在您希望这些包具有不同的生命周期时才有意义。当您想从另一个项目导入这些模块并且不希望整个包集合的开销时，它也可能有意义。一般来说：模块是相关的 Go 包的集合，它们作为一个单元一起进行版本控制。模块记录精确的依赖需求并创建可重现的构建。大多数情况下，版本控制存储库只包含一个在存储库根目录中定义的模块。（单个存储库支持多个模块，但通常这会比每个存储库一个模块导致更多的持续工作）。总结存储库、模块和包之间的关系：一个存储库包含一个或多个 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 namemypackage/          # v1.0.0anotherpackage/     # v0.5.1nested/dependency/  # v0.8.3您将需要在 中创建标签github.com/name/project，其名称与目录结构完全匹配，例如：mypackage/v1.0.0anotherpackage/v0.5.1nested/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。