From: https://studygolang.com/articles/31112?fr=sidebar
1. Enable go mod
go env -w GO111MODULE=on #Turn on MODULE go env -w GOPROXY=https://goproxy.cn,https://goproxy.io,direct #defaults to https://proxy.golang.org,direct
GO111MODULE can be set to: off, on, auto (default), as you can see from the GO111MODULE variable name, it is Go1. Dependent package management is not available until version 11.
- When off, go mod is not used, and the order in which dependent packages are found is the current project root directory/vendor, followed by $GOPATH/src (which was used before Golang version 1.11).
- When on, turn on go mod to find dependent packages that are go in the current project root directory. The mod file is a baseline, ignoring the $GOPATH and vendor folders and only going. Mod download dependency.
- For auto or not set, the go command enables or disables module support based on the current directory. Only if the current directory is outside $GOPATH/src and contains go itself. Mod file or in the containing go. Module support is only enabled when the mod file is in the directory.
GOPROXY is dependent on the package proxy address, since it is like golang. Relying packages like org/x require a wall-flip to download, so it is recommended that they be set to a domestic mirror address:
https://goproxy.cn The mirror address of GO maintained for Qiniuyun in China.
https://goproxy.io Is another mirror address in the country.
2. Initialize go.mod
Enter the project root directory (if the directory is named project1), initialize a moudle, the module name is your project name, must be English name, allow alphanumeric underscores and / but cannot start with /.
go mod init [Module name]
If our project root directory is in $GOPATH/src/, the module name can be left blank and is automatically generated, typically with the same name as the project root directory, such as project1 or github.com/project1; If the project root directory is not in $GOPATH/src/the module name must be filled in, and the module name can also be named like project1 or github.com/project1, that is, the module name does not necessarily correspond to a path, but if we use a path, such as github.com/project1, or move the project to $GOPATH/src/github later. COM directory.
After execution, a go is created in the current project root directory. Mod file, such as:
module project1 go 1.13
There is no dependent package information at this time.
3. Organize Dependent Packages
go mod tidy
After the command executes, go mod will go to the project file to find dependent packages and add the list of dependent packages to go. In the mod file, automatically delete dependent packages that have errors or are not in use.
4. Copy dependent packages to project vendor
go mod vendor
When the project is finished, we can also copy the dependent packages to the project root directory/vendor/, for archiving purposes, or we can actually do nothing like go.mod documentation is enough.
With vendor in the project root directory, you can compile as follows:
go build -mod vendor -o ./project1 //project1 is the compiled package name, or as follows, with the file name go build -mod vendor -o ./project1 main.go
5. Other Common Commands
Download dependent packages to local cache
go mod download
If you pull the code once before, it will go this time. Version information inside mod is cached in $GOPATH/pkg/mod/cache,
If the cache has this version information when downloading, download it with the version information inside the cache, otherwise download it again.
Note: If you have pulled a package from the tag version, if the information contained in the tag has been modified, you need to clear the cache to retrieve the updated tag information.
Clean up local dependency packages
go clean -modcache
The above command is a reverse operation of go mod download, which deletes the dependent package cache placed under $GOPATH/pkg/mod/cache. Sometimes the dependent package has errors and can be cleaned up before being downloaded to the local cache.
Add a single dependent package
go mod edit -require=golang.org/x/text
Remove a single dependent package
If we no longer use a package, we can remove it individually, such as:
go mod edit -droprequire=golang.org/x/text
Verify that the dependencies are correct
go mod verify
Explain why dependency is needed
go mod why
Verify the correctness of all dependent packages
go mod verify
6. go.mod Document Description
Go. The mod file can explain the management rules of dependent packages through require, replace, exclude statements:
The require statement is used to specify the essential dependent package
The replace statement specifies the address at which dependent packages need to be replaced, such as golang. Replace the org/x/text package with github.com/golang/text
The exclude statement specifies that dependency modules can be ignored
For example:
replace ( cloud.google.com/go => github.com/googleapis/google-cloud-go v0.34.0 github.com/go-tomb/tomb => gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7 go.opencensus.io => github.com/census-instrumentation/opencensus-go v0.19.0 go.uber.org/atomic => github.com/uber-go/atomic v1.3.2 go.uber.org/multierr => github.com/uber-go/multierr v1.1.0 go.uber.org/zap => github.com/uber-go/zap v1.9.1 golang.org/x/crypto => github.com/golang/crypto v0.0.0-20181001203147-e3636079e1a4 golang.org/x/lint => github.com/golang/lint v0.0.0-20181026193005-c67002cb31c3 golang.org/x/net => github.com/golang/net v0.0.0-20180826012351-8a410e7b638d golang.org/x/oauth2 => github.com/golang/oauth2 v0.0.0-20180821212333-d2e6202438be golang.org/x/sync => github.com/golang/sync v0.0.0-20181108010431-42b317875d0f golang.org/x/sys => github.com/golang/sys v0.0.0-20181116152217-5ac8a444bdc5 golang.org/x/text => github.com/golang/text v0.3.0 golang.org/x/time => github.com/golang/time v0.0.0-20180412165947-fbb02b2291d2 golang.org/x/tools => github.com/golang/tools v0.0.0-20181219222714-6e267b5cc78e google.golang.org/api => github.com/googleapis/google-api-go-client v0.0.0-20181220000619-583d854617af google.golang.org/appengine => github.com/golang/appengine v1.3.0 google.golang.org/genproto => github.com/google/go-genproto v0.0.0-20181219182458-5a97ab628bfb google.golang.org/grpc => github.com/grpc/grpc-go v1.17.0 gopkg.in/alecthomas/kingpin.v2 => github.com/alecthomas/kingpin v2.2.6+incompatible gopkg.in/mgo.v2 => github.com/go-mgo/mgo v0.0.0-20180705113604-9856a29383ce gopkg.in/vmihailenco/msgpack.v2 => github.com/vmihailenco/msgpack v2.9.1+incompatible gopkg.in/yaml.v2 => github.com/go-yaml/yaml v0.0.0-20181115110504-51d6538a90f8 labix.org/v2/mgo => github.com/go-mgo/mgo v0.0.0-20160801194620-b6121c6199b7 launchpad.net/gocheck => github.com/go-check/check v0.0.0-20180628173108-788fd7840127 )
Mainly include: golang.org google.golang.org gopkg.in go.uber.org cloud.google.com. There will be timeout downloads that cause compilation to fail. This is a replacement for the corresponding github library.
7. Use of go get
After using go mod, the way that go get pulls dependencies changes:
1. The old go get process is similar: git clone + go install. When the Go Module function is turned on, the go get process is only git clone or download.
2. Another difference between the old and new implementations is that the two packages are stored in different locations. The former is stored in the $GOPATH/src directory; The latter, stored in the $GOPATH/pkg/mod directory.
3. After the old go get retrieves the main package, it will cycle through the submodules under its repo. The new go get no longer supports submodule submodule pulling.
View downloadable versions of specified packages
go list -m -versions github.com/gogf/gf
Download Project Dependency
go get ./...
Pull the latest version (preferring tag)
go get golang.org/x/text@latest
Pull the latest commit of master branch
go get golang.org/x/text@master
Pull tag to v0.3.2 commit
go get golang.org/x/text@v0.3.2
Pull commit hash 342b231 and it will be converted to v0.3.2:
go get golang.org/x/text@342b2e
Specify version pull, pull v3 version
go get github.com/smartwalle/alipay/v3
To update
go get -u
8. Differences between go mod and original GOPATH
1. The environment variable GOPATH is no longer used to parse the imports package path, i.e. the original package under $GOPATH/src/, which cannot be found by import
2. When the Go Module function is turned on, the downloaded package will be stored with the $GOPATH/pkg/mod path
3. $GOPATH/bin path functionality remains
summary
At Go1. Prior to version 11, dependent package management was the package management method of GOPATH, which was not flexible and convenient. After version 1.11 was released, a new go mod management method was introduced. In official terms, this is an alternative to GOPATH, which integrates support for version control and package distribution. You can see that using package management methods such as nodejs for reference, project creation no longer needs to be placed in a fixed $GOPATH/src/path, with the domestic dependent package mirror source, the experience is smooth, recommended!