登录
首页 >  Golang >  Go问答

一个项目中的各个不同模块

来源:stackoverflow

时间:2024-03-11 19:54:25 413浏览 收藏

亲爱的编程学习爱好者,如果你点开了这篇文章,说明你对《一个项目中的各个不同模块》很感兴趣。本篇文章就来给大家详细解析一下,主要介绍一下,希望所有认真读完的童鞋们,都有实质性的提高。

问题内容

我一直在使用 go 模块,我想知道以下目录结构的最佳实践是什么:

project
├── go.mod
├── main.go
└── players
    ├── go.mod
    ├── players.go
    └── players_test.go

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

module github.com//

require (
    github.com//players v0.0.0
)

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

这允许我在我的 main.go 文件中执行 import "github.com//players"

现在这种方法可以工作,并且是从这里获取的,但我不确定这是否是正确的方法,或者这种方法是否只是用于在版本控制之外临时更新本地包。

另一个选项,似乎有点矫枉过正,是让每个模块都有自己的存储库?

tl;博士; - 在同一存储库中拥有多个模块并将它们导入其他模块/根 main.go 文件的最佳实践方法是什么?


解决方案


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

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

一般情况:

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

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

大多数情况下,版本控制存储库仅包含存储库根中定义的一个模块。 (单个存储库支持多个模块,但通常这会导致比每个存储库单个模块更多的持续工作)。

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

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

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

回答问题:

您可以按照您的方法中所示的方式来实现

我知道这是一个老问题,但是在管理一个存储库中的多个模块时,还有一些细节值得一提,使用或没有 go.work

tl;dr

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

go 模块详细信息

replace 无版本控制指令

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

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

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

带有版本控制

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

一个 go.mod,一个存储库

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

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

基于提交的版本控制

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

  • 要使 github.com/name/project 依赖于 github.com/name/project/players,您需要确保所需的代码位于远程存储库中。这是因为 github.com/name/project 将从远程存储库中提取代码并提交信息,即使存储库的本地副本上有相同的代码。这可确保 github.com/name/project/players 的版本取自提交参考,例如 v0.1.1-0.20220418015705-5f504416395d (参考: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 来指定您不希望跳过校验和验证的路径。

基于标签的版本控制

您可以使用 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 工作的父目录中有 go.work,请使用 github.com/name/project/players 等,该目录优先并使用本地文件。即使您在 go.mod 中指定了版本,情况也是如此。

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

go.work 据说是一个很少需要提交到存储库的文件。不过,您必须了解在父路径中包含 go.work 会产生什么影响。

--

参考文献:

旁注:

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

本篇关于《一个项目中的各个不同模块》的介绍就到此结束啦,但是学无止境,想要了解学习更多关于Golang的相关知识,请关注golang学习网公众号!

声明:本文转载于:stackoverflow 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>