Use go get for package management in go modules

Use go get for package management in go modules

Author: @apocelipes
This article is original by the author, please indicate the source for reprinting: https://www.cnblogs.com/apocelipes/p/9537659.html

---

In the previous article , we introduced the initial use of go modules. Now let's take a deeper look at how to use go get to manage dependencies in modules.

 

Package management under module

First of all, we introduced go mod edit to modify go.mod, but it has two flaws:

• The first is that its -require must accept the form of "package@version", which is indispensable, and it cannot recognize the master and latest flags stipulated in the document.
• Secondly, edit is only suitable for modifying the dependency version, renaming the package, and shielding a specific package. It is not suitable for adding dependencies.

The good news is that go get now has the ability to add/modify/update packages in modules.

To fully experience go modules, we need to choose a directory other than GOPATH, and set GO11MODULE=on, so that when using go get, it will only affect the current main module and will not pollute GOPATH.

This time I chose a toy project I was playing with to demonstrate the use of go modules in a project without package management. (For vendor migration, you can use go mod vendor -v, which will be introduced in detail later).

We clone the project to a non-GOPATH path, and then use

go mod init [project name]

Initialize the module. Initialized directory:

At this time go.mod is still empty, we know that go build will update go.mod, so let's go build first

By default, go get will be used to obtain the latest package. Now go.mod has been updated and the project has been successfully compiled. This is go.mod:

module schanclient

require (
    github.com/PuerkitoBio/goquery v1.4.1
    github.com/andybalholm/cascadia v1.0.0 // indirect
    github.com/chromedp/chromedp v0.1.2
    golang.org/x/net v0.0.0-20180826012351-8a410e7b638d // indirect
)

Indirect means that the package is dependent on the sub-module/package, but the main module is not directly imported, which is the so-called indirect reference.

Usually, go.mod does a good job of package management with the default behavior, but there are always some exceptions in life.

We see that chromedp uses version 0.1.2, which is the version three months ago. The latest commit was last month. Go mod edit needs to clearly specify the version number or commit time + checksum. Obviously this is very troublesome, no We hope.

So how can we use the latest version instead of the latest tags?

Or maybe we don't want the latest version, but a specific version of the package?

That's what version selection is all about.

 

New feature of go get - version selection

There used to be a solution like gopkg.in+go get, and the version selection supported by the new go get is a further extension of this solution. Look at a few rules:

• go get will automatically download and install the package, and then update it to go.mod
• You can use go get package[@version] to install the specified version of the package. When the version is not specified, the default behavior is the same as go get package@latest
• version can be in the form of vx.yz or directly use the checksum of commit, or it can be master or latest
• When version is latest, which is the default behavior, for packages with tags, the latest tag will be selected, for packages without tags, the latest commit will be selected
• When the version is master, regardless of whether the package is tagged or not, the latest commit of the master branch will be selected
• You can use >, >=, <, <= before version, indicating that the selected version must not exceed/below version, and the version that meets the latest condition within this range
• go get -u can update the package to the latest version
• go get -u=patch will only update minor versions, e.g. from v1.2.4 to v1.2.5
• When you want to modify the version of the package, you only need to go get package@specified version

Then we want to change chromedp to the latest version is very simple:

go get github.com/chromedp/chromedp@master

Now chromedp has been updated in go.mod:

module schanclient

require (
	github.com/PuerkitoBio/goquery v1.4.1
	github.com/andybalholm/cascadia v1.0.0 // indirect
	github.com/chromedp/chromedp v0.1.3-0.20180717231922-bf52fed0d3e6
	golang.org/x/net v0.0.0-20180826012351-8a410e7b638d // indirect
)

What if we now want to add additional packages?

Just use go get directly. For example, I want to use gorm to store data in the database:

go get github.com/jinzhu/gorm

Updated go.mod

module schanclient

require (
	github.com/PuerkitoBio/goquery v1.4.1
	github.com/andybalholm/cascadia v1.0.0 // indirect
	github.com/chromedp/chromedp v0.1.3-0.20180717231922-bf52fed0d3e6
	github.com/jinzhu/gorm v1.9.1 // indirect
	github.com/jinzhu/inflection v0.0.0-20180308033659-04140366298a // indirect
	golang.org/x/net v0.0.0-20180826012351-8a410e7b638d // indirect
)

We see that the latest version of gorm has been added, of course, because we did not import it in the main module, it is indirect.

If we want to use v1.9 gorm:

go get github.com/jinzhu/[email protected]

Unfortunately, the version selection is in order from major version to minor version. If there are v1.9 and v1.9.1, then when you specify v1.9, the version with the highest minor version number will be automatically selected, unless v1.9 is used No other v1.9.z tag exists, here is v1.9.1.

 

It is also worth mentioning that go build and go test will only add packages that are not in go.mod, and will not overwrite or change the rules introduced by go get, so don't worry about them conflicting.

 

Do you think it is very similar to venv+pip? Yes, this shows that go's package management tools are gradually modernized.

As for blocking packages, deleting packages, and renaming packages (such as packages that cannot be accessed by golang.org/x/...), these are the functions of go mod edit. For details, please refer to go help mod edit.

 

Because the information of go modules is not perfect, so I am also doing it while reading the document. It is inevitable that there will be omissions and mistakes. Welcome to correct me!

Tags:  golang