The module mechanism of go1.11 and the problem of Dep/govendor mechanism

Does the module mechanism and the Dep/govendor mechanism conflict?

Since the Go team launched the module mechanism, there have been some clashes between the go team and the DEP community, with a famous argument about the Go module argument, which gives the illusion that module mechanisms and dep/govendor mechanisms are incompatible. But careful analysis of the two operating mechanisms, in fact, there is no conflict, but rather complementary nature.

moduleThe mechanism is controlled by an environment variable GO111MODULE , which has three values: off、on、auto The default value is auto . In auto mode, when the $GOPATH/src path is under build , the third-party package is used by default, and vendor GOPATH GOPATH when compiled outside, the project is imported by default using go.mod settings. We know that the vendor mechanism GOPATH works only under the path, and GOPATH it is useless to go outside. So the module mechanism can be seen as vendor a complement to the mechanism, GOPATH within which it can dep/govendor import the dependency package into the vendor directory, and it also improves the flexibility of the go language, and our source code no longer has to be saved into GOPATH the The directory structure can be organized flexibly.

What is the use of the module mechanism?

• When all of the third-party packages you rely on are managed by the git server, it is well suited to use the module mechanism.

• When you use a large number of local third-party packages, it is not appropriate to use the module mechanism.

Because module the schema must be edited using a local third-party package go.mod , the replace command points to the local package directory.

Because of the network reasons, in our domestic use module mechanism is sometimes not very convenient, when we want to use the package from such golang.org blocked websites, we generally have to download to the local by other means, and then edit the go.mod replace command point to the local directory, so it is better to use The vendor way is convenient, unless you have a special reason, you must GOPATH save the source code outside. In this case, I recommend storing the downloaded third-party package in the vendor directory so that it can be compatible with the 非module mode.

When using a local private third-party package, the vendor pattern is convenient because the module pattern uses local third-party packages that must be edited go.mod , replace using local packages with commands.

First Glimpse Go module
The argument about Go module

End