Go 工程的依赖获取

Go 不愧是新时代的语言,其项目依赖的书写方式,实现了老夫很久之前的一个奢望:云依赖。照此路子,将来区块链相关的 IPFS 也许也能加入到底层技术支持栈里面来。

之前的依赖获取,只知道傻瓜式的 go get 就能够自动解决,昨天编译团队里其他小伙伴没有空维护的从 MinDoc 主干分叉出来的版本时才发现,竟然要用到一个叫 dep 的工具。将 dep 和 go get 执行后的本地文件树做一下对比的话,会发现组织方式上有大不同。

go get 会把依赖与主工程置于接近平等的地位,文件以直截了当的方式存放于 src 目录下。而 dep 则不然,它在与 src 平级的 pkg 目录下创建了属于自己的根目录 dep,所有依赖项目均在其下(中间其实还有一层 sources 目录)。各个依赖项目自己的顶级目录,在组织上选择了命名平坦化的路子。光说不够直观,举例,若依赖的项目是 github.com/golang/appengine,则 go get 的话,本地路径会是 src/github.com/golang/appengine,而 dep 管理下则会是 pkg/dep/sources/https—github.com-golang-appengine,然后,把它们搞到主项目的 vendor 目录下一份。

在过程中还发现了 Visual Studio Code 下,微软的 Go 插件 0.11.9 版本的一个 bug。它自动有 lint 功能,保存时会将无效 import 清理掉,项目依赖于 gopkg.in/russross/blackfriday.v2,调用语句则形如 blackfriday.Run() 这样的,这导致每次 Ctrl-S 都会把相应的 import 语句强行干掉,从而导致编译失败。每次眼睁睁看着我自己刚刚粘贴好的那行代码不翼而飞,还是挺诡异的。

另,昨天趁着促销,在 Microsoft Store 里 71 人民币入了 X410 备用,也许用处不大。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注