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

Question

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

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

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

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

---

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

Answer 1

先回答最后一个问题：是的，类似。

然后是正文部分。

---

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，其实也有很多不完善的地方，比如无法引入两个版本不同的同名依赖等问题。总之未来还会有很长的一段路要走，也算是流行语言的必由之路吧。

Answer 2

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

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