Project version management with Golang 1.11 module

Go 1.11 has experimental support for modules, most subcommands know how to handle a module, such as run build install get list mod subcommands, and third-party tools may be supported later. To go 1.12 will remove the GOPATH support, the go get command will become only to get the module, not as it is now directly get a bare package.

You can GO111MODULE turn module support on or off with an environment variable, which has three optional values:,, off on auto , the default value is auto .

• GO111MODULE=offWithout module support, go will look for packages from the Gopath and vendor folders.
• GO111MODULE=onModule support, go ignores the Gopath and vendor folders, depending on the go.mod download only.
• GO111MODULE=autoOn the $GOPATH/src outside and when the root directory has go.mod files, the module support is turned on.

When using the module, GOPATH it is meaningless, but it will be stored in the download of dependencies $GOPATH/src/mod , will also put go install the results in $GOPATH/bin .

Defining modules

The module root directory and all of its subdirectories are composed of modules, files exist under the root directory go.mod , and subdirectories will always find files to the parent directory and the master directory go.mod .

The module path refers to the import path of the module root and the prefix of the other subdirectory import path. The go.mod first line of the file defines the module path, which is counted as a module.

go.modThe remainder of the file is used to define dependencies and dependent versions of the current module, as well as to exclude dependencies and substitution dependencies.

module example.com/m require (    golang.org/x/text v0.3.0    gopkg.in/yaml.v2 v2.1.0 )replace (    golang.org/x/text => github.com/golang/text v0.3.0)

This file is not handwritten, you can use the go mod -init -module example.com/m go.mod first generated line, the rest of the file does not have to worry about, in the execution go build , the go test go list command will be dependent on the dependency of the automatic generation of require statements.

The official recommendation is to maintain this file regularly, keeping dependencies clean. For domestic users, manual maintenance of this file is inevitable, because you need to golang.org/x/text replace the github.com/golang/text AH. No need to replace the dependency in the hack way as before, GOPATH I still have the old thinking in the beginning, actually want to replace the download cache of the module, but if the Goproxy function can be replaced.

Go List command

• go list -mYou can view the current dependencies and versions

Go MoD command

This subcommand is used to process the go.mod file, which we have already seen in the previous section go mod -init .

• go mod -fmtFormat go.mod file.
• go mod -syncgo.modThis operation does not change dependent versions by removing unwanted dependencies and new dependencies.
• go mod -require=path@versionAdd dependent or modified dependent version, here Support fuzzy match version number, details can see go get the usage below.
• go mod -vendorGenerate the Vendor folder.

Other self- go help mod viewing.

Go get command

Gets the specific version of the dependency that is used to upgrade and downgrade. Files can be automatically modified go.mod , and dependent version numbers may change. In the go.mod use exclude of excluded packages, cannot go get come down.

Unlike before, the new version go get can be signed at the end and @ used to specify versions.

It requires the warehouse must be in the format of the v1.2.0 tag, like v1.2 a few 0 is not possible, it must be a semantic, v prefixed version number.

go get github.com/gorilla/mux    # 匹配最新的一个 taggo get github.com/gorilla/mux@latest    # 和上面一样go get github.com/gorilla/mux@v1.6.2    # 匹配 v1.6.2go get github.com/gorilla/mux@e3702bed2 # 匹配 v1.6.2go get github.com/gorilla/mux@c856192   # 匹配 c85619274f5dgo get github.com/gorilla/mux@master    # 匹配 master 分支

latestMatch the latest tag.

v1.2.6The full version of the notation.

v1, v1.2 match the latest version with this prefix, and if the latest version is 1.2.7 , they will match 1.2.7 .

c856192Version hash prefixes, branch names, and non-semantic tags are go.mod all used in conventions v0.0.0-20180517173623-c85619274f5d and are also known as pseudo versions.

go getCan be blurred to match the version number, but the go.mod file only reflects the full version number, that is, v1.2.0 v0.0.0-20180517173623-c85619274f5d , just do not need to write so long version number, with go get or above the go mod -require fuzzy match, it will match to the full version number of the go.mod file.

Go Build command

go build -getmode=vendorWith the support of the module enabled, this can be used to return to the era of using vendor.