Go package management speed pass, an article is enough, no longer need to worry about the package will not be fired

This article has participated in the activity of “New person creation Ceremony”, and started the road of digging gold creation together.

preface

It’s interesting to read some go books recently: one of the books was last printed in March 2017, and golang package management’s upstart Go Module came out with Go1.11 in August 2018 — so, it’s not in the book.

I am impressed by the rapid development of Golang and the current projectgo module,go vendor(a popular package management tool after GO1.5) intertwined, even seen from time to timego pathThe package management pattern is in some articlesThe resurgenceI think it is important to clarify the reasons for this so that you can choose the appropriate package management mode.Whitey, no brain choicego moduleIs bad? Is it necessary to learn outdated things?

In fact, I think you can do without it, but you need to understand why it is not recommended or even deprecated, and it is hard to define what is an outdated technology, as I used vendor in my project. Many Golang learners may have some background in other languages and be quick to learn go. Java has Maven, so go must have xx package management tools as well. Open the search engine and enter Go for quick start, installation and project construction. Some people find go Path, some find Govendor, and some find Go Module.

That’s why I wanted to write an article summary (in case the Go Module isn’t recommended one day! GOPATH/ SRC, GOPATH/bin, GOPATH/ PKG /mod.

Two commands

Go install XXX (download XXX third-party binary executable)

Go get XXX (download XXX third-party dependency package)

Download executables/third party dependencies to local where? Different package management tools differ, as described below.

Two paths

GOROOT: The go installation directory, which is similar to the Java JDK and houses some built-in development packages and tools.
GOPATH: The workspace designated by GO to hold the go project code and third-party dependency packages.

#MAC can use go env to view go-related environment variables, similar to Windows
go env
GOROOT="/usr/local/go"
GOPATH="/Users/baize/GolandProjects/"
Copy the code

Three package management tools

Go Path [not recommended]

Go Path, the earliest dependency package management approach (Go1.0), enables GOPATH mode (note the difference between GOPATH mode and GOPATH path, which are two context) and requires that all project code requirements be placed in the GOPATH/ SRC directory. After the project goes through go build XXX, Go Install XXX or Go get XXX commands, the pulled third-party XXX dependency packages will be placed in the GOPATH/ SRC directory, and the generated binary executable files will be placed in the GOPATH/bin directory. The generated intermediate cache files are stored under GOPATH/ PKG.

Question: There is no concept of version control in GOPATH mode. When you perform Go Get, you always get the latest dependency package and download it to GOPATH/ SRC. If you have two projects that depend on v1 and v2 versions of the same package, there will be conflicts. In GOPATH mode, the dependency import path in both projects is the same, so both projects get the V2 version.

Command: Obviously, go get in GOPATH mode will pull code to GOPATH/ SRC, which is no longer recommended.

Govendor [not recommended]

After Go 1.5, Go provided the GO15VENDOREXPERIMENT environment variable (which is enabled by default in Go 1.6) and the Govendor package management tool, It is used to adjust the application path search during go build to the current project /vendor directory, effectively solving the problem that different projects use their own independent dependent package directory. Compiling the Go code will first look for the dependency packages in the Vendor directory. If the vendor directory is not found, then look in GOPATH.

Advantages: Project construction is fast and can work in CI/CD processes that cannot be connected to the Internet because of full integration of third-party dependencies with the project.

Problem: Redundancy increases with the abandonment of dependency reuse

Download: go install github.com/kardianos/govendor (govendor is third party executable file, download the executable file using the go install, use the go get to also go, but there will be a warning).

Command: govendor –help to view all commands (use go get XXX to download XXX dependencies into $GOPATH/ SRC first, at this time govendor package management is based on GOPATH mode)

The command	function
govendor init	Initialize the`vendor`directory
govendor add	Add a package to`vendor`Directories (related dependencies are retrieved from $GOPATH/ SRC)
govendor add +external	Add all external packages to`vendor`directory
govendor get	Pull dependency packages`vendor`directory

Then I saw the following in govendor’s codebase: 👇 (this README was updated two years ago, and the library hasn’t been maintained for a long time, um…) .

go module

Go Module is officially available as a package management tool starting from Go1.11 and enabled by default starting from Go1.13. In GOMODULE mode, all dependent packages are stored in GOPATH/ PKG /mod. All third-party binary executables are stored in GOPATH/bin. Project projects can be stored outside GOPATH. However, the project is required to have the go.mod file (which can be initialized by using the go mod init command).

Both GOMODULE and GOPATH specify the location of dependent packages instead of placing them in the project. The difference is that the GOMODULE’s go.mod file records the specific version of dependent packages. It also solves the problem that different projects cannot rely on different versions of the same package in GOPATH mode.

To enable GOPATH mode, the project directory must be under GOPATH/ SRC. To use GO MODULE mode, you need to enable configuration first. After Go1.13, you can run the following command to enable the GO MODULE.

MAC :(similar to Windows)

#Light on will also not work, need to work with go.mod, below
export GO111MODULE=on
export GO111MODULE=off
#When the project path is in$GOPATHSet it to GO111MODULE = ON when the project path is inside GOPATH, even if go.mod is present
export GO111MODULE=auto
Copy the code

Go mod command: go help mod View related help commands (govendor is a third-party executable, but the go mod command is shipped with go, do not need to go install)

The command	function
go mod init	To initialize the current folder, create`go.mod`In fact, if your environment has GO111MODULE=on, creating a project using a tool like Goland will automatically generate go.mod
go mod tidy	Package sorting (more delete, less pull), before using the natural is the need to import the library
go mod vendor	Copy the dependency package to the project file`vendor`directory

When GO111MODULE=on and the project contains go.mod files, the packages or binary executables downloaded by executing go get XXX or go Install XXX will be placed in the GOPATH/ PKG /mod and GOPATH/bin directories.

Go mod vendor:

Go mod vendor is not recommended. Why does GOMODULE provide the command associated with the go mod vendor function?

In fact, if you need to use Vendor mode to manage packages, it must be in one of two situations:

Work inGOPATHIn mode, Go versions are earlier than 1.11 or GO111MODULE=off (becauseThis approach relies on the GOPATH pattern, so it is no longer recommended)
Work inGO MODULEUnder the mode, but still use vendor to manage dependent packages, and Go Mod Vendor belongs to this situation (kind of preserving the survival of vendor, after all, there are still use scenarios, andGo mod vendor uses the GOMODULE pattern as a base, ditching the Gopath-based Govendor).

conclusion

Code word is not easy, three even is the truth ~

Just built a small wechat group, welcome to join the chat, prepare for autumn together!

P3-juejin.byteimg.com/tos-cn-i-k3…

My micro channel, also welcome to pay attention to the public number [programmer Bai Ze], take you to a little more nonsense programmers