该文翻译自https://medium.com/i-can-haz-downtime/dep-101-c85e8ab6ed45#.hbngswi0e
我很高兴在过去几个月和几个其他gopher开发的一个原型依赖管理工具,名为dep。
dep是去年开始由Peter Bourgon组织的项目的一部分。由于我参与开发了一个“godep”,Go的OG依赖管理工具(继承自Keith Rarick),因此加入了dep项目的团队。
除了我自己和Peter,团队的其他成员是Jessie Frazelle,Andrew Gerrand和Sam Boyer。 Andrew是Google Go team的一员。 Jessie在Google工作,并参与过大型Go项目,如Docker和Kubernetes。 Sam维护gps。
该团队发布了一系列我们工作过程中的进展信息。到目前为止,各种其他工具作者和相关方也以不同的方式参与这一项目。
起初
假设我们正在使用github.com/gorilla/mux编写一个Web应用程序。 这里是一些代码,让我们开始:
package main
import (
"net/http"
"os"
"github.com/gorilla/mux"
)
func main() {
r := mux.NewRouter()
r.Handle("/", http.FileServer(http.Dir(".")))
http.ListenAndServe(":"+os.Getenv("PORT"), r)
}
在现有项目上第一次使用dep时,需要运行dep init。
dep init将在GOPATH中已经包含github.com/gorilla/mux,manifest.json文件将包括它。我先运行如下命令:
go get -u github.com/gorilla/mux
所以在我的$GOPATH中github.com/gorilla/mux的分支是master。如果我的$GOPATH中的版本匹配Semver tag(例如:v1.2.3),那么将使用该tag的名称。
dep可以跨越架构和go版本。我们可以将github.com/gorilla/mux与旧版本的Go(<1.7.0)的github.com/gorilla/context包结合使用。当我最后运行
go get -u github.com/gorilla/mux
的时候,我运行的是Go 1.7.5,所以github.com/gorilla/context包不在我的$GOPATH。因为可能是编译项目所需的依赖,它会包含在lock.json文件中。在这种场景下,如果从属项目有一个semver兼容的release tag,dep会选择最新的版本。在这种情况下是github.com/gorilla/context的v1.1。
因为github.com/gorilla/mux不包含manifest.json文件,dep不知道github.com/gorilla/mux目前是否能与github.com/gorilla/context@v1.1配合使用。dep一般使用在依赖的manifest.json文件中找到的约束。
dep init包括所有依赖关系(包括递归依赖)以及在lock.json文件中使用的确切版本。
对于示例应用程序,这将创建以下两个文件:
lock.json
{
"memo": "d741a3bed21fe6cae9d67c523b0a343859882b2f246f2a293e2676cfacd5a2ce",
"projects": [
{
"name": "github.com/gorilla/context",
"version": "v1.1",
"revision": "a85d2e53ba63bdea074dbbbb5983f0516974e87b",
"packages": [
"."
]
},
{
"name": "github.com/gorilla/mux",
"branch": "master",
"revision": "392c28fe23e1c45ddba891b0320b3b5df220beea",
"packages": [
"."
]
}
]
}
manifest.json
{
"dependencies": {
"github.com/gorilla/mux": {
"branch": "master"
}
}
}
确保项目可以编译
在运行dep init之后,应该运行dep ensure以便将构建项目所需的软件包副本填充在vendor/目录。 这确保任何项目的依赖项都包括在lock文件和vendor目录中。 如果你想确保记录所有的依赖,运行dep ensure。
添加依赖
添加另一个依赖项,只需在代码中使用它。 当需要检查你的工作时,你需要运行dep ensure更新lock.json文件和vendor/。 这将锁定项目到每个依赖项的最新发布版本。
如果最新版本不合适呢?
如果需要指定版本,可以使用ensure命令的备用形式,如:dep ensure github.com/gorilla/mux@\^1.3.0。该命令修改manifest.json文件,约束dep使用github.com/gorilla/mux的\^v1.3.0版本,解析依赖关系树并更新vendor/中的依赖关系。在示例应用程序上,因为dep已经选择了最新的可用版本1.3.0。但是,以后的更新(dep ensure -update)将不再跟踪主分支,而是使用semver标记的版本≥1.3.0和<2.0.0。
dep主要使用Rust cargo类似的操作符来选择依赖的版本。这些包括\^,~和=。还有一个更严格的,向前兼容的匹配比\^使用~。例如,dep确保github.com/com/gorilla/mux@~1.2.0将匹配大于等于1.2.0和小于1.3.0任何版本。要锁定到特定版本,请使用=(e.x. dep ensure github.com/com/gorilla/mux@=1.2.0)。在未来,dep计划将\^作为默认前缀。
保持更新
要保持项目的依赖关系最新使用dep ensure -update,它将所有依赖关系更新为由manifest.json中的约束所允许的最新版本,并忽略lock.json的内容。 将新版本写入vendor/,并在lock.json中更新相应的元数据。
在将来,可以用dep ensure -update 更新单个依赖关系。
Status
当缺少依赖项时,dep status会告诉您哪些软件包缺失。 例如,这里是dep status的输出:
$ dep status
PROJECT MISSING PACKAGES
github.com/boltdb/bolt [github.com/boltdb/bolt]
如果项目的lock.json是最新的,dep status命令显示所有依赖项的列表,作为项目,并为每个:
应用约束
选版本
所选修订版本
最新版本或修订版本
使用的软件包数量。
将bolt添加到示例项目并运行dep后,确保更新lock.json和vendor/,dep status如下所示:
$ dep status
PROJECT CONSTRAINT VERSION REVISION LATEST PKGS USED
github.com/boltdb/bolt * v1.3.0 583e893 v1.3.0 1
github.com/gorilla/context * v1.1 a85d2e5 v1.1 1
github.com/gorilla/mux ^1.3.0 v1.3.0 392c28f v1.3.0 1
golang.org/x/sys * branch master 7a6e564 7a6e564 1
这两种模式可以在将来合并。
移除依赖
dep remove
未来
dep仍然处于实验阶段,有许多问题需要解决和很多工作要做。 我希望这篇文章清楚地显示了一些如何使用工具的例子。 使用方式可能会随着时间的推移通过社区反馈和请求而改变。 如果你有一些空闲时间,并有兴趣参与一些Go工具开发,请现在开始。
谢谢阅读!
有疑问加站长微信联系(非本文作者)