同一项目中的多个模块

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文件中执行操作。

现在，此方法可行并从此处采用，但是我不确定这是否是正确的方法，或者该方法是否仅用于在版本控制之外临时更新本地包。

另一个选择，似乎有点过大，是使每个模块都有自己的存储库？

TL; DR; -在同一存储库中包含多个模块并将其导入其他模块/根main.go文件中的最佳实践方法是什么？

Answer 1

我知道这是一个老问题，但是在管理一个存储库中的多个模块（无论是否带有go.work.

长话短说

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

Go 模块详细信息

replace无版本控制的指令

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

使用模块路径go.mod定义的main 后，模块无法进行可重现的构建，因为指令的依赖目标可能已更新其内容。如果 的依赖目标被许多模块使用，这可能会特别成问题。这种公共包中的任何更改都可能导致所有依赖项同时发生行为改变。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（参考：“伪版本”的详细信息）
• 模块名称必须与目录结构匹配。例如，如果您有单个存储库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指定您不希望跳过校验和验证的路径。

基于标签的版本控制

您可以使用 Git 标签，而不是使用提交 SHA。

但由于一个存储库中可能有许多模块，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父路径中的影响。

--

参考：

• https://go.dev/doc/modules/managing-source：围绕存储库设置的讨论
• https://go.dev/ref/mod：Go 模块参考

边注：

我在日本主办的 Go 会议上对此进行了演讲 -如果您想通过示例了解更多信息，您可以在这里找到一些演示代码、幻灯片等。

Answer 2

2022 年，最佳实践方法是在同一存储库中拥有多个模块并将它们导入其他模块。
这是由新的“go 模块工作区”支持的。随Go 1.18 和新的 go work 命令
一起发布。

请参阅“提案：cmd/go 中的多模块工作区”和问题 45713：

工作目录或包含目录中存在go.work文件将使 go 命令进入工作空间模式。
该go.work文件指定组成工作区的一组本地模块。
在工作区模式下调用时，该go命令将始终选择这些模块和一组一致的依赖项。

go.work 文件：

go 1.18

directory (
    ./baz // foo.org/bar/baz
    ./tools // golang.org/x/tools
)

replace golang.org/x/net => example.com/fork/net v1.4.5

您现在拥有CL 355689

cmd/go: 添加GOWORK到go env命令

GOWORK如果处于工作区模式，则将设置为go.work文件的路径，否则将为空。

Answer 3

通常，模块应该是软件包的集合。

但是仍然可以创建单个软件包的模块。正如Volker所说，这仅在您希望这些程序包具有不同的生命周期时才有意义。当您想从另一个项目中导入这些模块，而不想要整个软件包集合的开销时，这也可能很有意义。

一般来说：

模块是相关的Go软件包的集合，这些Go软件包一起作为一个单元进行了版本控制。

模块记录精确的依赖要求并创建可复制的构建。

通常，版本控制存储库仅包含在存储库根目录中定义的一个模块。（在一个存储库中支持多个模块，但是通常，与每个存储库中的单个模块相比，这将导致持续不断的工作）。

总结存储库，模块和软件包之间的关系：

1. 一个存储库包含一个或多个Go模块。
2. 每个模块包含一个或多个Go软件包。
3. 每个软件包都在一个目录中包含一个或多个Go源文件。

报价来源：https : //github.com/golang/go/wiki/Modules#modules

要回答这个问题：

您可以按照方法中显示的方式进行操作：