在 Buffalo 1.0 的路上:全面支持 Go Modules

Buffalo

自 2019年12月1日起,Buffalo 和所有相关软件包将不再支持 $GOPATH 并且Go 的版本最低要求为 1.13

如果您当前正在使用 Go Modules,那么这些更改很可能不会影响您。但是,如果您使用的是 $GOPATH,我强烈建议您尽早迁移。

自 12月1日起,虽然我们不会刻意破坏 $GOPATH 的使用,但是将不再保证其可用性。如果出现不兼容情况,我们也将不再修复。


一开始的 $GOPATH

$GOPATH 已经存在了很长一段时间,Buffalo 一开始就构建在此机制上。多年来,此机制为 Go 社区提供了很好的支持,但它的时代已经过去了。

Buffalo 首次发布时,所有 Go 开发都是在 $GOPATH 中完成的,这是 Go Tool工作所需的指定文件夹布局。这意味着所有的 Buffalo 应用程序都需要在这个文件夹布局中,在正确的位置编写。

基于 $GOPATH 中应用程序的元数据来编写工具非常困难。需要围绕文件系统进行猜测和各种的 Hack,以确保 Buffalo 应用程序正常运行;如果运行不正常,则开发人员只能花大量时间去调查其原因。

多年来围绕 $GOPATH 的问题有很多讨论,包括从缺少依赖项到 $GOPATH 大小写与磁盘上文件夹结构不匹配问题。当然这还有 Windows 和 Unix 文件系统之间的差异以及这些差异可能导致的问题。

并且也没法确保使用 $GOPATH 的两个 Build 可以完全相同(缺少依赖包的版本控制)。Go 团队意识到了这个问题,并尝试使用 vendoring 来解决。

vendor 目录

Go 1.5 是新增了 vendor 目录。该目录可以保存您的应用程序依赖关系,Go 工具将使用该目录而不是 $GOPATH 来解析依赖关系。很快的,像 Glide 这样的工具开始出现来管理 vendor目录。

当 Dep 工具出现时,由于当时相信 Go 团队支持这个解决方案,社区迅速跟进,Dep 很快成为管理依赖关系的标准。

Buffalo 同样将其集成到工具链中。此时,Buffalo 此时有两个不同的开发工作流,$GOPATHvendor,同时还得保证三大厂商:Windows、Mac 和 Linux 下都能正常使用。

vendor 目录并不能解决 $GOPATH 的所有问题,例如不能确保正确的文件路径,但它确实有助于构建相同的 Build。

Go Modules

然后在 2018 年初出现了模块。Russ Cox(Go team 核心成员) 宣布 VGO( versioned Go)。 后来在Go1.11中引入Go工具链时,它被重新命名为 Go Modules。虽然我不同意使用 Modules 所做的所有决定,但它们确实提供了更好的体验,不仅是为开发人员,而且也为我这样的工具制造商提供了更好的体验。

不需要 $GOPATH

对于 Modules 来讲,没有必需的如 $GOPATH的文件夹结构。应用程序可以在开发人员希望的任何地方编写。这意味着,不再要求代码存放在某个固定的位置。

不需要 vendor 文件夹

不再需要 vendor 目录以及管理该目录所需的工具。 Go Tool 可以自动管理应用程序的依赖关系,而无需用户参与。最后一点使为 Go 编写工具变得容易得多。例如,Buffalo 不需要运行一系列 go get 命令来确保下载所有依赖关系,Go 工具会自动执行此操作。

一致的 Build

最终,Modules 提供了可复现、一致性的 Build。这对于确保一致的开发体验来说至关重要。

并非一切都那么美好

Go Modules 虽然解决了Buffalo 的很多环境问题,但它也导致了更多的问题。例如,Modules 的语义版本化规则不能与 Dep 这样的工具兼容,如设置不当,也会破坏那些使用 $GOPATH的项目。

Buffalo 支持所有这些依赖方案,乘以三大操作系统。多年来,这导致了许多问题,许多错误,混乱和复杂的代码,不胜枚举。

在版本 v0.15.0 中,Buffalo 放弃了对 Dep 和 vendor 文件夹的支持。这有助于清理一些代码,并使某些任务和决策更容易,但还不够。

仅支持 Go Modules 和 Go 1.13

仅支持 Go Modules 且将 Go 版本需求限定在 1.13 以上,我们可以为 Buffalo 用户提供更稳定、更可预测和更强大的工具集。我们可以清理代码,关闭 Bug,并开始进行更多、更多的必要改进,这些改进和更改在支持 $GOPATH 时是很难做到。

通过仅支持 Modules,我们可以提供更好的体验。我们有像 golang.org/x/tools/go/packages 和 github.com/gobuffalo/here ,这使得收集模块和程序包的元数据变得更加容易,并且更加准确。我们可以清理旧的,错误的代码路径。利用 Modules 机制和版本控制,安全地进行一些重大改进。

2020 年我们有很多计划,通过 Go Modules,我们有信心带来更多激动人心的功能。

本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。

原文地址:https://blog.gobuffalo.io/the-road-to-1-...

译文地址:https://learnku.com/buffalo/t/39049

本文为协同翻译文章,如您发现瑕疵请点击「改进」按钮提交优化建议
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!