前端外刊评论 2017-12-14
上一篇文章中我们已经成功的运行了go的代码,这是我们迈出的最基础的一步。
一个项目通常会依赖很多外部的库,当依赖的库比较多的时候,手工管理就会比较麻烦,这个时候就需要包管理工具出场了,帮你管理好所有依赖的库。
php项目中使用composer,javascript项目中使用npm,那么在go项目中,我们需要使用什么?
当前go的包管理工具有glide、godep、govendor和gvt等,相关对比的文章可以查看《go依赖包管理工具对比》。
功能对比可以参考如下内容(虽然跟上面文章比较的工具有些不同),内容来自《Go Package Manager Comparison》
Glide | GB | Godep | Govendor | |
---|---|---|---|---|
Semantic Versions | ✓ | ✓ | ✕ | ✓ |
Semantic Version Ranges | ✓ | ✕ | ✕ | ✕ |
Resolves dependency trees including versions | ✓ | ✕ | ✕ | ✕ |
Uses common range syntax (similar to PHP, JavaScript, etc) | ✓ | ✕ | ✕ | ✕ |
Tries to import from other package managers | ✓ | ✕ | ✕ | ✕ |
Copies from the GOPATH | ✕* | ✕ | ✓ | ✓ |
Works with the go toolchain | ✓ | ✕ | ✓ | ✓ |
Locks for reproducible builds | ✓ | ✓ | ✓ | ✓ |
Allows package/version checked into VCS or installed on demand | ✓ | ✓ | ✕ | ✓ |
Aliased repos (e.g., using forks) | ✓ | ✕ | ✕ | ✓ |
Plugin extensibility model | ✓ | ✓ | ✕ | ✕ |
Supports deleting unused repos for cleanup (opt-in) | ✓ | ✕ | ✕ | ✓ |
根据我们的需求和了解,选择了使用glide,当然大家也可以选择其他包管理工具。
我们来熟悉一下glide的命令
# 初始化glide配置 glide create glide init # 添加新的包 glide get [package name] # 根据glide.yaml更新包 glide update glide up # 根据glide.yaml安装包 glide install # 返回当前项目的名称 glide name # 列出当前项目已安装的包 glide list # 替换包的镜像 glide mirror set [original] [replacement] glide mirror set [original] [replacement] --vcs [type] # 移除包的镜像 glide mirror remove [original] # 获取包的镜像列表 glide mirror list
glide mirror特别适用于不能访问一些站点,导致很Golang的依赖包不能通过go get下载的情况。可以通过配置将墙了的版本库 URL 映射到没被墙的 URL,甚至也可以映射到本地版本库。
掌握上面的命令就可以使用glide了,是不是很简单?
我们再来看一一个完整的glide.yaml的内容
package: github.com/Masterminds/glide homepage: https://masterminds.github.io/glide license: MIT owners: - name: Matt Butcher email: [email protected] homepage: http://technosophos.com - name: Matt Farina email: [email protected] homepage: https://www.mattfarina.com ignore: - appengine excludeDirs: - node_modules import: - package: gopkg.in/yaml.v2 - package: github.com/Masterminds/vcs version: ^1.2.0 repo: [email protected]:Masterminds/vcs vcs: git - package: github.com/codegangsta/cli version: f89effe81c1ece9c5b0fda359ebd9cf65f169a51 - package: github.com/Masterminds/semver version: ^1.0.0 # 测试导入包 testImport: - package: github.com/arschles/assert
glide.yaml中的这些元素的解释如下:
package
:顶部的 package 是它所在GOPATH的位置,glide 将从该位置下开始导包。
homepage
:该项目的详情页面。
license
:许可证标识,可以是SPDX license字符串或文件路径。
owners
:项目的所有者信息,便于接受漏洞信息。
ignore
:忽略导入的包,注意是包而不是目录。
excludeDirs
:排除扫描依赖的目录。
import
:import 的包列表:
package
:导入包的名称,必填。软件包名称遵循go工具所用的相同模式。这意味着:1、映射到VCS远程位置的软件包名称以.git,.bzr,.hg或.svn结尾。 例如,example.com/foo/pkg.git/subpkg。2、GitHub, BitBucket, Launchpad, IBM Bluemix Services, and Go on Google Source是特殊情况,不需要 VCS 扩展。
version
:可以为semantic version, semantic version range, branch, tag 或者 commit id。
repo
:如果包名称不是repo位置或这是一个私人存储库,它可以去这里。 该软件包将从repo签出并放在软件包名称指定的位置。 这允许使用fork。
vcs
:要使用的VCS,如git,hg,bzr或svn。仅当无法从名称中检测到类型时才需要。例如,以.git或GitHub结尾的仓库可以被检测为Git。 对于Bitbucket的repo,我们可以联系API来发现类型。
subpackages
:在存储库中使用的包的记录。这不包括存储库中的所有包,而是包括正在使用的包。
os
:用于过滤的操作系统的列表。如果设置它将比较当前运行时操作系统与指定的操作系统,并且只有获取匹配的依赖。如果未设置过滤,则跳过。这些名称与构建标志和GOOS环境变量中使用的名称相同。
arch
:用于过滤的体系结构列表。如果设置它将比较当前运行时架构与指定的架构,并且只有在匹配时获取依赖关系。如果未设置过滤,则跳过。名称与构建标志和GOARCH环境变量中使用的名称相同。
testImport
:在导入中未列出的测试中使用的软件包列表。每个包具有与导入下列出的相同的详细信息。
glide版本号指定规则如下:
=: equal (aliased to no operator) !=: not equal >: greater than <: less than >=: greater than or equal to <=: less than or equal to 1.2 - 1.4.5 which is equivalent to >= 1.2, <= 1.4.5 2.3.4 - 4.5 which is equivalent to >= 2.3.4, <= 4.5 1.2.x is equivalent to >= 1.2.0, < 1.3.0 >= 1.2.x is equivalent to >= 1.2.0 <= 2.x is equivalent to < 3 * is equivalent to >= 0.0.0 ~1.2.3 is equivalent to >= 1.2.3, < 1.3.0 ~1 is equivalent to >= 1, < 2 ~2.3 is equivalent to >= 2.3, < 2.4 ~1.2.x is equivalent to >= 1.2.0, < 1.3.0 ~1.x is equivalent to >= 1, < 2 ^1.2.3 is equivalent to >= 1.2.3, < 2.0.0 ^1.2.x is equivalent to >= 1.2.0, < 2.0.0 ^2.3 is equivalent to >= 2.3, < 3 ^2.x is equivalent to >= 2.0.0, < 3
要注意的是安装完成之后,会生成glide.lock文件,锁定安装包的版本。