Golang Learning-Package management tools Glide

This is a creation in Article, where the information may have evolved or changed.

We have successfully run the go code in the previous article, which is the most basic step we have taken.

A project usually relies on a lot of external libraries, when relying on more cubby, manual management will be more troublesome, this time you need package management tools to play, to help you manage all dependent libraries.

Using NPM in the PHP project using the Composer,javascript project, what do we need to use in the Go project?

Selection of package dependent tools

The current package management tools for go include glide, GODEP, Govendor, and GVT, and related articles can be viewed in the "Go-dependent package management tool comparison".

The function comparison can refer to the following (although some of the tools compared to the above article), the content from "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 the other package managers	✓	✕	✕	✕
Copies from the Gopath	✕*	✕	✓	✓
Works with the Go toolchain	✓	✕	✓	✓
Locks for reproducible builds	✓	✓	✓	✓
Allows package/version checked to VCS or installed on demand	✓	✓	✕	✓
aliased repos (e.g., using forks)	✓	✕	✕	✓
Plugin Extensibility Model	✓	✓	✕	✕
Supports deleting unused repos for cleanup (opt-in)	✓	✕	✕	✓

According to our needs and understanding, we have chosen to use glide, of course, you can choose other package management tools.

Glide command

Let's get acquainted with Glide's orders.

# 初始化glide配置glide createglide init# 添加新的包glide get [package name]# 根据glide.yaml更新包glide updateglide 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 is especially useful when you cannot access some sites, causing very golang dependent packages to not be downloaded through go get. You can map a wall-based repository URL to a URL that is not a wall, or even to a local repository.

You can use glide to master the above commands, is it simple?

Glide.yaml parsing

Let's take a look at a complete glide.yaml.

package: github.com/Masterminds/glidehomepage: https://masterminds.github.io/glidelicense: MITowners:- name: Matt Butcher  email: technosophos@gmail.com  homepage: http://technosophos.com- name: Matt Farina  email: matt@mattfarina.com  homepage: https://www.mattfarina.comignore:- appengineexcludeDirs:- node_modulesimport:- package: gopkg.in/yaml.v2- package: github.com/Masterminds/vcs  version: ^1.2.0  repo:    git@github.com: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

The explanations for these elements in Glide.yaml are as follows:

• package: The package at the top is the location of the Gopath where it is located, and Glide will start the guide from that location.

• homepage: The details page of the project.

• license: The license ID, which can be a SPDX license string or file path.

• owners: Project owner information for easy access to vulnerability information.

• ignore: Ignore the imported package, note that it is a package instead of a directory.

• excludeDirs: Excludes directories that are dependent on the scan.

• Import : List of packages for import:

  • Package : The name of the importer is required. The package name follows the same pattern used by the Go tool. This means: 1. The package name mapped to the VCS remote location ends with. git,.bzr,.hg or. svn. For example, example.com/foo/pkg.git/subpkg. 2, GitHub, BitBucket, Launchpad, IBM Bluemix Services, and Go on Google source are special cases and do not require VCS extensions.

  • version : Can be semantic version, semantic version range, branch, tag, or commit ID.

  • repo : If the package name is not repo location or this is a private repository, it can go here. The package will be checked out from repo and placed in the location specified by the package name. This allows the use of fork.

  • vcs : VCs to use, such as GIT,HG,BZR or SVN. Required only if the type cannot be detected from the name. For example, a repository that ends in. git or github can be detected as git. For BitBucket's repo, we can contact the API to discover the type.

  • subpackages : The record of the package that is used in the repository. This does not include all the packages in the repository, but rather includes the packages being used.

  • os : The list of operating systems used for filtering. If set it compares the current run-time operating system with the specified operating system, and only gets a matching dependency. If no filtering is set, the Skip is skipped. The names are the same as those used in the build flags and GOOS environment variables.

  • arch : List of architectures for filtering. If set it compares the current run-time schema with the specified schema, and only gets the dependencies when matching. If no filtering is set, the Skip is skipped. The name is the same as the name used in the build flags and goarch environment variables.

• testImport: The list of packages used in tests that are not listed in the import. Each package has the same details as the import listed below.

The glide version number specifies the following rules:

=: equal (aliased to no operator)!=: not equal>: greater than<: less than>=: greater than or equal to<=: less than or equal to1.2 - 1.4.5 which is equivalent to >= 1.2, <= 1.4.52.3.4 - 4.5 which is equivalent to >= 2.3.4, <= 4.51.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

Note that after the installation is complete, the Glide.lock file is generated and the version of the installation package is locked.

Reference excerpt article

• Golang Dependency Management tool: Glide from beginner to proficient use
• Golang Package Management tool Glide, you deserve to have