Golang Package Management Tools Glide Introduction

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

Golang Package Management Tools Glide Introduction

Objective

Golang is a very interesting, concise and powerful development language, and it's a pleasure to develop concurrent/parallel programs. Here I feel some of the benefits:

• No less a lot of code format style controversy, forced to unify the style of how good;
• Compile fast, no longer wait for a long time, to compile the project (test-driven development naturally more cool);
• There is also no one in the same project group that is using a different subset of the same language. However, this situation is pervasive in both C # and the Java world;
• Easy cross-platform (of course Java is doing well, c#/.net or hard ...)
• This is a very concise, simple, clear programming language (the keyword is very few AH)
• Package dependencies are very interesting to handle;
• The error handling mechanism is interesting, and the individual feels that it is more convenient and more reasonable than C#/java's exception handling mechanism.
• The interesting, non-intrusive interface implementation of object-oriented programming is awesome.
• Use combinations instead of inheritance
  Some things are not, like templates, this thing has a big controversy, the official also has a clear response. Yes, why do I have to have a template? Do you have to? Is that so critical? If not, go is not the best choice for this environment.

There is also a problem with package management, and there is no official best management solution, there are a lot of home-made solutions in the go world. The go language package is not centrally managed by using the go get command to pull from the remote code base (Github.com,goolge code, etc.), skipping the constraints of the central repository directly, allowing the code to pull directly based on the source code version Control Library, Collaboration between developers is directly dependent on source code versioning. The concept of the library version is removed directly. There is no obvious package version identification, the feeling is still a bit uncomfortable, the official recommendation is to copy the externally dependent code to their own controllable source of the repository, for consent management. Thus, the controllable management of the dependent packages is achieved.

1.5 version of the Vendor directory feature, the official wiki recommends a variety of package management tools to support this feature such as: GODEP, GV, GVT, Glide, Govendor, etc. I like glide better. In addition, as programmer FQ seems to be the necessary skills, turn a good wall, in order to keep up with the pace, just put the knife down the feel, how a cool word. Don't ask me how to FQ, find Niang, she knows.

Glide

Glide is the package management tool for go. Support the semantic version, support Git, SVN, and so on, support go toolchain, support vendor directory, pour from GODEP, GB, GPM, Gom, support private repos and forks.

The structure of the project directory using Glide management is as follows:

- $GOPATH/src/myProject (Your project)  |  |-- glide.yaml  |  |-- glide.lock  |  |-- main.go (Your main go code can live here)  |  |-- mySubpackage (You can create your own subpackages, too)  |    |  |    |-- foo.go  |  |-- vendor       |-- github.com            |            |-- Masterminds                  |                  |-- ... etc.

Installation

$ curl https://glide.sh/get | sh

Initialization

$ glide init

Initialize, glide scans the code directory, creates a Glide.yaml file, and records all dependencies in the file.

Edit Configuration

$ edit glide.yaml

By modifying the Glide.yaml file, you can add version information, and so on, which is not a required step.

Parsing download Package dependencies

$ glide update

Or

$ glide up

Download and update all the dependent packages listed in Glide.yaml and place them in the vendor directory. Glide also recursively gets any dependencies that are required for a dependent package, including dependent items defined in the configuration file. Glide recursively acquires dependencies that identify projects that are managed by glide, GODEP, GB, Gom, and gpm.

When a dependency is made to a specific version, a file named Glide.lock is created or updated. For example, if a version in Glide.yaml is specified in a range (for example: ^1.2.3), then glide will set a specific commit ID (commit ID) in Glide.yaml. This will allow for repeated installations (see Glide Install command).

You can use the-V flag to remove the nested vendor/directory from the acquired dependency package.

Install a specific version

When you need to install a prepared version of the package from the Glide.lock file, you can use the Install command:

glide install

The command will read the Glide.lock file, and Glide will provide a warning when the Glide.lock file and Glide.yaml are out of sync, as Glide.yaml changes. When you run the Glide up command to update the dependency tree, the Glide.lock file is rebuilt.

View dependent names in Glide.yaml

$ glide name

View dependency Lists

$ glide list

View Help

$ glide help

See Glide version Information

  $ glide--version