golang 的第三方包管理机制和 Python 有什么不同?

ponponon
  • 1.5k

我一直用 Python ,对于其包管理方式熟悉和喜欢。

但是最近学习 golang 的时候,遇到了很多困惑,比如 golang 没有 pythonpip 包管理器用来下载和管理第三方包,好像也没有一个 site-packages 目录统一存放这些第三方包,情况是这样的吗?

那请问 golang 是如何解决这些问题的呢?

参考一个知乎提问:golang的包管理模式设计的是否合理?


golang 貌似有一个 go mod,请问和这个是类似 pip 的东西吗?

回复
阅读 949
2 个回答
然后去远足
  • 34.8k
✓ 已被采纳

先回答最后一个问题:是的,类似。

然后是正文部分。


Golang 的包管理机制一直是被人所诟病的,不是啥好设计。

这门语言本身就来自于 Google 内部需求,原型期压根就是 Google 专属的玩意儿。Google 大家都知道,monorepo 先行者和布道者,别说 Golang 项目了、全公司所有项目都在一个大 repo 下,任何修改代码的变更都要想办法保证整个 repo 不出问题,这种时候一个 $GOPATH 既省事儿、又够用,不需要关心依赖问题,简直完美。

但等到大家用 Golang 的时候,抓瞎了,想必你已经感受到痛苦了。

当然社区已经意识到这个问题了,所以也在努力尝试解决了,但这玩意儿吧肯定不是一蹴而就的。(类比 Node.js 里的 npm 有很多坑哔设计已经积重难返了)。

目前为止 Golang 已经经历过几个包管理机制了:

  • 2012 年 Go 1.0 最早的 $GOPATH,全局依赖一把梭。
  • 2015 年 Go 1.5 实验性引入、到 2016 年 Go 1.7 正式确定的 vendor,终于每个项目有自己单独的依赖管理了,但不好意思,还没有版本控制。
  • 2017 年 Go 1.9 实验性引入的 go dep,后来因为社区与 Google 分歧过大,现在已经被砍了(这是归档仓库 https://github.com/golang/dep),不过总算有个比较成型的包管理了。
  • 2018 年 Go 1.11 实验性引入、到 2019 年 Go 1.13 正式确定的 go mod,在 Golang 诞生的第 7 个年头,终于“千呼万唤始出来”了。

这些都是 Golang 官方团队出的,来自纯社区的方案就更多了,这里就不一一列举了。

此外,在 go dep、go mod 出现之前,为了解决依赖管理问题,社区内还流行过一段 Bazel(类似 Make 的一种构建系统,也是 Google 开源的),但这个东西就很重量级了,对于小项目来说也很不方便,但那能怎么办呢 —— 也没别的用啊 😂

就算是现在的 go mod,其实也有很多不完善的地方,比如无法引入两个版本不同的同名依赖等问题。总之未来还会有很长的一段路要走,也算是流行语言的必由之路吧。

子部
  • 848

现在几乎都是使用 go mod site-packagesgo 里面同样有类似的。 执行go mod vendor 命令,会生成一个vendor目录,里面就是所有依赖框架的源码。

不要看以前过期的教程,执着于src目录。现在都快1.18了。好像是1.13版本go mod 就完善了。

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
宣传栏