所以现在 Go 到底应该用什么包管理器？

[liuzhaowei55]

手头项目有有 Go 写的，但自己有段时间没有关注 Go 了，之前官方有钦定一个包管理器，现在主流的是哪个？

[yanjinbin]

@huiyifyj 请问下 go mod 垃圾在哪? 真心不懂 求问 , 尝试了下 demo 觉得还好啊

[mnhkahn]

go mod

[silenceshell]

go mod。可以搭配 gocenter 食用，口感更佳

https://ieevee.com/tech/2019/02/19/go-mod-proxy.html

[2bab]

Go Mod，毋庸置疑。

要说 Go 的这些管理器哪里难用，其实是因为跟其他平台比，比如 Maven 和 NPM，所以才显得它太基础。

讲道理就得举个例子，比如是否可以暴露 API 让我写点脚本管理一些依赖的细节，我有 100 个直接依赖，然后带来 500 个间接依赖，可能为了兼容，我不一定就按照『优先版本高的』原则去采纳每个间接依赖，这方面 Gradle 可能就很 easy 的实现了。

[haozibi]

推荐是 go mod，但是在 Mac 下 用 go mod 管理的 VSCode 有点卡，所以我暂时用 dep

[huiyifyj]

@yanjinbin #21
版本号有时候太难看了，尤其是那些没有打 tag 的 git 依赖库。
没有中央仓库，想想如果依赖库的 git 仓库被删除，会产生很多问题。
对比 npm,maven,gradle,cargo,pypi，go mod 有些不办理，也不方便。期待以后的改善吧，其实可以借鉴 rust 的 cargo。听说以后会有官方中央仓库。

[silenceshell]

@huiyifyj
现在可以用 GoCenter，用封装的 goc，能满足需求。
说是 2019 年会有官方的 center。

[huiyifyj]

@silenceshell #27
去查了下，仓库太少了，发现还不如我现在用的 goproxy.io 。

[ecrazy]

go mod 比 dep 好用

[littlewing]

glide

[chenqh]

@silenceshell 现在不是 2019 年吗

[mason961125]

go mod，然后所有依赖整理到 vendor，push 的时候带着 vendor。

[THaGKI9]

@janxin #8 超级难用，感谢推荐

[THaGKI9]

@THaGKI9 #33 哎呀 at 错了

[fivestrong]

go 的包管理是真垃圾，感觉还没 rust 的 cargo 好用。

[blless]

go mod 我觉得已经可以了，中心仓库对项目其实也没啥提升？依赖库被删不放心可以自己 fork 一个，用两年也没看见被删的库。包管理这种东西我真觉得够用就好，而且明明 go get 易用性实用性都很强，我敢说大部分项目 go get 就搞定了

[ericgui]

@ecrazy dep 是官方的包管理器吧？

[Sparetire]

"你没有 xx 特性 /功能" "某某有也没啥提升"
"你没有 xx 特性 /功能" "够用就好"
"你没有 xx 特性 /功能" "在进步，好很多了，多努力"
"你为什么没有 xx 特性 /功能" "某某更烂你咋不说"
也许还会有诸如
"又不是不能用"
"你是不是针对*"
"太平洋又没加盖(划掉，走错片场了)，开源的觉得不好用有本事你就提 PR 啊"
类似的逻辑在哪都能见到很多呢。。不过我这条回复对解决楼主问题是毫无帮助，和问题也毫不相干，只是对本帖众多回复的一个观察

[OldPanda]

[go mod]( https://github.com/golang/go/wiki/Modules) +1

[blless]

@Sparetire 何必阴阳怪气的呢直接点名就好啊，不服可以反驳。至少目前我们自己项目用 go mod 之前用 govendor，都是把依赖直接固化在项目内。单元测试 覆盖测试 持续集成都是没有问题的。我说对项目提升不大也是建立在至少目前我们自己场景没有遇见啥坑的情况下说的。中央仓库对我上面那条场景有提升？
真要说有啥问题，一个是翻墙拉依赖，还有个引用的两个库依赖同一个不同版本的包这种。前者 goproxy.io 上面有人提过了，自己内网搭建一个代理都可以。后者写项目两年了，实际压根没遇到。所以现在到底 go 的包管理做成啥样你才会觉得够用？