在 Buffalo 1.0 的路上:全面支持 Go Modules
自 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 此时有两个不同的开发工作流,$GOPATH
和 vendor
,同时还得保证三大厂商: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 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
推荐文章: