before GO1.5-GOPATH
Before GO1.5 with GOPATH and GOROOT these two environment variables to determine the location of the package.
GOROOT is to inform the current installation location go, compiled system library sdk time to go from GOROOT.
GOPATH purpose is to inform the go, when you need code, where to look. Note that the code here, including the reference code of the item and external projects. GOPATH may vary from project to re-set. Starting go 1.8, if GOPATH is not set, there will be a default value on Unix is $ HOME / go, on Windows as% USERPROFILE% / go
There will be three directory GOPATH: src, bin, pkg.
-
src directory: Find the code compile time go places
-
bin directory: go get, godep this tool when bin binary file download destination
-
pkg directory: lib compiler generated files are stored where.
go allows code to import different code libraries, e.g. github.com, k8s.io, golang.org like; code needs to import, the GET command may be used to take down go into GOPATH corresponding directory. For example go get github.com/silenceshell/hcache, it will be downloaded to $GOPATH/src/github.com/silenceshell/hcachego, when other items import github.com/silenceshell/hcache, they also will be able to find the corresponding code.
See here will understand, go for it, does not really care that your code is internal or external, in short, are GOPATH, the path to import any packages are starting from GOPATH; the only difference is that the internal the package is dependent on developers to write their own, dependent on the external package is go get down.
Problems:
-
We can not distinguish between versions, so that developers make to the package name as the last item versioning
-
List of dependencies / relationships can not be persisted to local, need to find all the dependencies and then go get one
-
Rely on local global warehouse ($ GOPATH / GOROOT), the library can not be placed in a local warehouse ($ PROJECT_HOME / vendor)
GO1.5-vendor
GO1.5 use vendor need to manually set the environment variable GO15VENDOREXPERIMENT=1, GO1.6 the environment variable is set to 1 by default, in version 1.7, the environment variable has been removed, enabled by default vendor characteristics.
The project must be in the $GOPATH/srcdirectory
In the directory of the project to add a directory to hold the external vendor packages, in this mode, it will rely on third-party source code downloaded to the local, can have their own different vendor under different projects. But doing so has introduced a new problem, because with the increasing dependence of the project, code base will be growing, especially in the front end of a lot of projects with resources, tens to hundreds of M M are very common, your project it may depend on the contents of a point, but integrates all resources.
go vendor management tools
-
godep
-
govendgirtin
-
glide
go to the official wiki a more comprehensive comparison .
godep more intuitive, users are also a little more, some personal small items can be used; glide more feature-rich, closer maven (eg glide.lock with the maven pom.xml relatively similar, you can specify get a version), the new project consider using glide.
GO1.11-go modules
Based vgo evolved, it is Golang official package management tool.
configure
Modules are currently not enabled by default, can be turned on or off by GO111MODULE environment variable, which has three possible values: off, on, auto, default is auto.
-
off. Close support, go look for the package from GOPATH and vendor folders.
-
on. Open support, go ignores GOPATH and vendor folder, just download the dependencies according to go.mod.
-
auto. When the project
$GOPATH/srcoutside the time, and the project root directory go.mod file, open the module support, or still use GOPATH and vendor.
go modules use:
add dependencies
go mod init example.com/hello
go mod command generates a go.modfile, go.modthe file is only present in the module root directory in. Subdirectory package module having a path and the introduction path subdirectory path thereof. For example, if we create a subdirectory of the world, you do not need (not want) to run go mod init there. The package will automatically be recognized as example.com/hellopart of the module, the path of introduction example.com/hello/world.
go command uses go.moda specific module version dependency listed introduced to resolve. When confronted it not by the go.modimport module provided in any package, goes command will automatically find the latest version of the module containing the package, and add it to go.modthe. ( "Recent" is defined as the most recent mark stable (non-pre-release) version, or the latest pre-release version of the mark, or the latest version of unlabeled.) In our example, go test the new import rsc.io/quoteresolve to rsc.io/quote v1.5.2block it Download the rsc.io/quotetwo dependencies used, namely rsc.io/samplerand golang.org/x/text. Only direct dependencies recorded in the go.modfile.
go modules in the download package GOPATH/pkg/mod, which is said earlier, 'maven way'; installation of command still $GOPATH/bin.
In addition to go.mod, go command also maintains a file named go.sum, which contains the contents of a particular module version is expected to cryptographic hashes
go command go.sum file to ensure that the same position in the future to retrieve and download the first download these modules to ensure that your project does not depend on the module due to the malicious, accidental or otherwise accidentally changed. Should go.mod and go.sum are checked to version control.
go list -m all # list all current modules and dependency
update dependencies
For upgrades on minor levels:
go get golang.org/x/text # automatically download the latest version
May pass, may appear incompatible version,
List -m -versions rsc.io/ Go Sampler # listed in this module available label version Go GET rsc.io / Sampler @ v1. 3.1 # download the appropriate version, pay attention to information @ plus version, without version information default @latest
For upgrades on major levels:
Each different major versions Go module (v1, v2, etc.) using a different module path: from the beginning v2, the path must end with a major version. In an example, rsc.io / quote is no longer v3 rsc.io/quote: but identified by the module path rsc.io/quote/v3. This convention is called semantic import version control, which is not compatible with the package (with different major versions of the package) provides a different name. Instead, rsc.io / quote should be backwards compatible with the v1.6.0 v1.5.2, so it reuses the name rsc.io/quote. (In the previous section, rsc.io / sampler v1.99.99 you should have backward compatibility with rsc.io/sampler v1.3.0, but the error or incorrect assumptions about the client module behavior can happen.)
go command allows to build up a release that contains any route specific module, i.e., each major version up: a rsc.io/quote, a rsc.io/quote/v2, a rsc.io/quote/ v3, and so on. This provides clear rules on individual modules may repeat the path of the module: the program can not be used simultaneously rsc.io/quote v1.5.2 and rsc.io/quote v1.6.0 to build. At the same time, allowing different major versions of modules (because they have different paths) so that the user modules can be gradually upgraded to a new major version. In this example, we want to use rsc / quote / v3 v3.1.0 in quote.Concurrency, but not yet ready to migrate to use the rsc.io/quote v1.5.2. In a large program or code library, incremental migration capability is particularly important.
remove unused dependencies
Although some of us may not use the module, but go list -m all still displayed, as well as go.modthere will not automatically be deleted. After all packages only check module and all possible combinations of marker construct these packages, you can remove the dependencies. Common build command does not load this information, so it can not safely remove the dependencies.
go mod tidy # remove unused modules
Reference:
https://ieevee.com/tech/2017/07/10/go-import.html
http://www.sohu.com/a/330500438_470018
https://blog.golang.org/using-go-modules
https://juejin.im/post/5c6ac37cf265da2de7134242