Introduction to using go get for package management in go modules

Package management under module

First we introduced go mod edit to modify go.mod, but it has Two flaws:

1. First, its -require must accept the form of "package@version", which is indispensable, and it cannot recognize the master and latest flags specified in the document.

2. Secondly, edit is only suitable for modifying dependency versions, renaming packages, and blocking specific packages. 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 select a directory other than GOPATH and set GO11MODULE=on. In this way, using go get will only affect the current main module and will not pollute GOPATH.

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

go mod init [project name]

to initialize the module. Initialized directory:

At this time go.mod is still empty. We know that go build will update go.mod, so we 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 the meaning of 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 It means that this package is dependent on the sub-module/package, but the main module is not directly imported and used, which is the so-called indirect reference.

Usually, go.mod can complete package management well using 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 cumbersome and not what we want.

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

Or maybe we don’t want the latest version and need a specific version of the package?

This is the content of version selection.

New features of go get - version selection

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

go get will automatically download and install the package, and then update it to go.mod

can be used go get package[@version] to install the specified version of the package. When version is not specified, the default behavior is the same as go get package@latest

version can be in the form of vx.y.z or directly use the commit checksum, or It can be master or latest

When version is latest, it 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 version is master, regardless of whether the package is tagged, the latest commit of the master branch will be selected.

You can use >, >=, <, <= before version to indicate the selected version. It must not exceed/below the version. The versions within this range that meet the latest conditions

go get -u can update the package to the latest version

go get -u=patch will only update the minor version , for example, from v1.2.4 to v1.2.5

When you want to modify the package version, you only need to go get package@specified version

Then we want to use chromedp instead 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 want to add additional packages now?

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

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 the latest version The gorm has been added, of course because we did not import it in the main module, so it is indirect.

If we want to use v1.9 gorm:

go get github.com/jinzhu/gorm@v1.9

Unfortunately, the version selection is from the major version to the minor version. If there are v1.9 and v1.9.1, then when When you specify v1.9, the version with the highest minor version number will be automatically selected, unless there is no other v1.9.z tag except v1.9, which is v1.9.1 in this case.

Another point worth mentioning is 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 there is no need to worry about them conflicting.

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

As for blocking packages, deleting packages and renaming packages (such as inaccessible packages at golang.org/x/...), these are the functions of go mod edit. For details, please see go help mod edit .

Recommended:

go language tutorial

The above is the detailed content of Introduction to using go get for package management in go modules. For more information, please follow other related articles on the PHP Chinese website!