0. Introduction

Recently joined goose factory to learn k8s, management relies Go go modules use more than 1.11 in the group, thus finishing the relevant information
This article seriously refer to the original: the first glimpse Go module

1. Traditional management package depends Golang

Golang design heavily influenced by Google trunk development model:
- All developers based backbone trunk / mainline development: committed to the trunk or get the latest code from the trunk (synchronized to the local workspace)
- When the release to establish Release branch, release branch is essentially a snapshot of a particular moment of the code trunk
- bug fix and improvements to enhance the release branch code also typically submitted to the trunk (commit), then cherry-pick to a release branch

go get the design Golang by Google within a single code repository (single monorepo) and the development model based on the influence of the trunk (trunk / mainline based): access only trunk / mainline latest version
Go get the code will be placed acquired $ GOPATH / src below, and go build will follow the import path to search package at $ GOROOT / src and $ GOPATH / src below
Due to go get get individual package repo is the trunk / mainline code, so Go before 1.5 Go compiler is based on objective Go program depends on the package trunk / mainline code to compile
Problems caused by such mechanisms include:
- trunk / mainline code that changes every moment, the code acquiring different people at different times may be different (i.e., can not be achieved reproduceable build)
- Dependencies of the trunk evolution may lead to code that does not compile
In order to achieve reporduceable build, Go 1.5 introduced a mechanism govendor
- Golang compiler will take precedence in the search vendor-dependent third-party packages
- Developers will depend on the particular version of the package is stored in a vendor below and submit it to the code base
- So in theory, everyone will get the same results compiled in order to achieve reporduceable build
In the years after the Go 1.5 release, Gopher had the attention has focused on how to use the vendor to resolve package dependencies
- From the vendor to manually add dependencies
- Manually update the dependencies, into a crowd-born dependency management tool: for example: govendor, glide and dep-called quasi-official tool
- According to today's efforts to try to solve the mainstream ideas such as: "Diamond-type dependency" and other problems
Just think dep Gopher will naturally be upgraded to go toolchain part of the time, vgo turned out
In the original Go tools to quickly and easily implement a package dependency management program Go Native, vgo go modules is the predecessor

2. go modules Introduction

Usually we will create a group package in a warehouse, the warehouse path such as: github.com/bigwhite/gocmpp will go package as the import path of (import path)
Under GOPATH mode, the compiler in accordance with the package path $ GOPATH / src or stepwise directory matches the vendor
Go 1.8 version, if the developer does not explicitly set $ GOPATH, Go will be given a default value GOPATH (on linux is $ HOME / go)
Go 1.11 to such a set of packages in the same warehouse below gives a new abstraction: module
And enable a new file go.mod record of meta-information module
A repository module corresponds to a module or a plurality of
In go modules, the repository will place a top-level directory go.mod files, each file defines a go.mod Module1, while the directory file is placed go.mod Module1 referred root directory (usually corresponding to a root directory warehouse , but not required)
module root directory and all its subdirectories are packages under attributable to the module, in addition to its own subdirectory that contains the file go.mod
In go modules, Golang compiler will not search target program depends on third-party vendor packages in GOPATH below and the following

3. Try using a go modules

Set the environment variable GO111MODULE:
- GO111MODULE = off: no module support, go from GOPATH will find the package and vendor file folder
- GO111MODULE = on: module supports, go ignores GOPATH and vendor folder and depend only on go.mod download
- GO111MODULE = auto: when go.mod file in $ GOPATH / src and outside the root directory, open the module support
When using the module, GOPATH is meaningless, but still will download dependencies are stored in $ GOPATH / pkg / mod, the result will be to go install placed $ GOPATH / bin
Create a directory under hello ~ / test, then write hello.go (in this case not GOPATH $)

// hello.go
package main

import "bitbucket.org/bigwhite/c"

func main() {
    c.CallC()
}

View Code

Creating go.mod in ~ / test / hello:

// go.mod
module hello

View Code

Construction of hello.go:

$ go build hello.go
go: finding bitbucket.org/bigwhite/c v1.3.0
go: downloading bitbucket.org/bigwhite/c v1.3.0
go: extracting bitbucket.org/bigwhite/c v1.3.0
go: finding bitbucket.org/bigwhite/d v1.2.0
go: downloading bitbucket.org/bigwhite/d v1.2.0
go: extracting bitbucket.org/bigwhite/d v1.2.0

$ ./hello.exe
call C: v1.3.0
   --> call D:
        call D: v1.2.0
   --> call D end

View Code

View go.mod:

$ cat go.mod
// go.mod
module hello

go 1.12

require bitbucket.org/bigwhite/c v1.3.0 // indirect

View Code

indirect means the packet is not directly referenced by the main mod, but indirectly referenced by other packages mod
If you then add a direct reference to the mod, it will delete the above indirect reference
go compiler download cache dependencies in $ GOPATH / pkg / mod below:

$ pwd
/e/Coding/Golang/go/pkg/mod/cache/download

$ Ls 
bitbucket.org / github.com/ golang.org/ gopkg. in / sigs.k8s.io/ 
cloud.google.com / go.uber.org/ google.golang.org/ k8s.io/

View Code

Specific implementation:

$ ./hello.exe
call C: v1.3.0
   --> call D:
        call D: v1.2.0
   --> call D end

View Code

Golang (eight) go modules learning

0. Introduction

1. Traditional management package depends Golang

2. go modules Introduction

3. Try using a go modules

4. References

Guess you like