Hi, everyone.

I am Ming, in their own learning Golang this time, I wrote a detailed study notes on my personal number WeChat public Go programming time, for the language, I was a beginner, so writing should fit in with the new to classmates, if you are just learning the language, don’t focus on prevention, Learn together and grow together.

Online blog: golang.iswbm.com Github:github.com/iswbm/GolangCodingTime

In the past, the package dependency management of Go language has been criticized by everyone. Go officials have been trying to provide developers with a more convenient package management scheme, from the original GOPATH to Go VENDOR, and then to the latest Go Modules. Although there have been a lot of detour, But I ended up with a decent solution like Go Modules.

At present, the most mainstream package dependency management method is to use the official recommended Go Modules. This is not some time ago, Go 1.14 was released, the official said, strongly recommend you to use Go Modules, and have confidence that it can be used in production.

This article will cover the use of Go Modules at length, but before that, I’ll give you a brief overview of the first two solutions, GOPATH and Go Vendor. I think this is necessary, because only by understanding its development process, can we know how difficult and significant the coming of Go Modules is.

1. The oldest GOPATH

GOPATH should be familiar to many of you.

You can think of it as a working directory, and under this working directory, there is usually the following directory structure

Each directory stores different files

  • Bin: stores binary executable files generated after compilation
  • PKG: stores files generated after compilation.afile
  • SRC: Store the source code of the project, either your own code, or the packages you download from Go Get

The GOPATH mode is the way to manage all of your packages and everyone else’s packages in the $GOPATH/ SRC directory.

In this mode, when you use Go Install, the generated executable is placed under $GOPATH/bin

If you are installing a library, the.a files will be generated in the corresponding platform directory under $GOPATH/ PKG (a combination of GOOS and GOARCH), and the.a files will be generated.

GOOS stands for target operating systems, including Darwin (Mac), Linux, Windows, Android, NetBSD, OpenBSD, Solaris, Plan9, etc

GOARCH represents the target architecture, commonly arm, AMD64 and so on

Both of these are variables in the go env, which you can check with the go env variable name

At this point, you probably don’t see any problems until you start developing programs using GOPATH. The most serious of these are version management issues, because GOPATH has no concept of versioning.

Here are some of the problems you’re bound to encounter with GOPATH:

  • You cannot use the specified version of the package in your project because the import method is the same for different versions of the package
  • When someone else runs your application, there is no guarantee that he or she is downloading the package version you want. If someone else uses another version, the application may not work properly
  • Locally, a package can only keep one version, which means that all projects you develop locally have to use the same version of the package, which is almost impossible.

2. Transition of go Vendor mode

To solve the problem of not being able to use multiple version libraries for different projects under GOPATH, Go V1.5 started supporting vendor.

In the old days of GOPATH, all projects shared a single GOPATH, and when they needed to import their dependencies, they all came to GOPATH. In GOPATH mode, only one version of the third-party library was allowed.

The solution is to create a vendor directory under each project, and the dependencies required by each project will only be downloaded to its own vendor directory, and the dependency packages between projects do not affect each other. At compile time, v1.5’s Go iment is set to open GO15VENDOREXPERIMENT=1. This variable defaults to 1 in V1.6, but after V1.7 it has been removed and vendor feature is enabled by default, so you don’t need to manually set it), which will increase the priority of the dependent package search path in the Vendor directory (compared to GOPATH).

The order of priority for its search packages, from highest to lowest, is this

  • The vendor directory under the current package
  • Look in the parent directory until you find the vendor directory under SRC
  • Look in the GOROOT directory
  • Look for dependency packages under GOPATH

Although this solution solves some problems, it is not perfect.

  • If multiple projects use the same version of the same package, the package will live in different directories on the machine, wasting disk space and making it impossible to centrally manage third-party packages (scattered all over the place).

  • And if you want to share your project open source, you need to upload all depend on you pack all, while others are used in addition to your project source code, and download all depends on the package, to ensure that others use, not as version problems lead to the project will not run as normal as you expected.

These seemingly non-problems will make our development and use process very uncomfortable. Although I am a beginner and have not used Go Vendor, I have a clear premonition that this scheme will still crash me.

3. Go Mod comes out of nowhere

Go Modules was released in V1.11, and in the latest release, V1.14, it was officially announced that it was mature enough to be used in production.

As of v1.11, the Go env has an environment variable: GO111MODULE, 111 here, is actually the symbol of V1.11. It seems that go likes this naming method very much. For example, when vendor appeared, there was also a GO15VENDOREXPERIMENT environment variable, where 15, The vendor represented was only born in V1.5.

GO111MODULE is a switch that enables you to turn go Mod mode on or off.

It has three optional values: off, on, and auto. The default is auto.

  1. GO111MODULE=offDisables module support from theGOPATHandvendorFind packages in folders.
  2. GO111MODULE=onEnable module support, ignored at compile timeGOPATHandvendorFolder, only according togo.modDownload dependencies.
  3. GO111MODULE=autoWhen the project is in$GOPATH/srcExternal and in the project root directorygo.modFiles automatically enable module support.

With the go mod, GOPATH (which no one will use) and GOVENDOR will be and are being phased out, but if your project still uses those soon-to-be obsolete package dependency management schemes, be sure to set GO111MODULE to off.

How do you set it up? I can use the go env command, if I want to start go mod, use this command

$ go env -w GO111MODULE="on"Copy the code

4. Go Mod dependency management

Next, we’ll demonstrate how Go Modules manage package dependencies.

The go mod no longer relies on $GOPATH to create projects without GOPATH, so we created a go_test directory in our home directory to create my project. Details are as follows:

Next, go to the project directory and initialize the Go Modules by executing the following command

Next, it’s important to look at where does Go Install install the downloaded package?

As we observed above, when using Go Modules mode, two more files are generated in the project directory: go.mod and go.sum.

These two files are at the heart of the Go Modules, and I have to cover them here.

Go. The mod file

The content of go.mod is relatively easy to understand

  • Line 1: the reference path for the module
  • Line 2: The GO version used by the project
  • Line 3: Direct dependency packages and their versions required by the project

In practice, you’ll see more complex go.mod files, such as the one below

1.14 the require module github.com/BingmingWong/module-test go (example.com/apple v0.1.2 example.com/banana v1.2.3 example.com/banana/v2 v2.3.4 example.com/pear // indirect example.com/strawberry // incompatible) exclude example.com/banana v1.2.4 replace (golang.org/x/crypto v0.0.0-20180820150726-614D502a4dac => github.com/golang/crypto V0.0.0-20180820150726-614d502a4dac golang.org/x/net v0.0.0-20180821023952-922F4815f713 => github.com/golang/net V0.0.0-20180826012351 -8a410e7b638d golang.org/x/text v0.3.0 => github.com/golang/text v0.3.0)Copy the code

There are mainly two more flags:

  • exclude: Ignores the dependency packages of the specified version
  • replace: Since fan walls are required for each package accessed domestically at golang.org/x, you can use replace in go.mod to replace the github library.

Go. Sum file

The go.sum file, on the other hand, is a bit more complicated and dense.

As you can see, it’s a lot of stuff, but it’s not hard to understand

Each line is composed of the module path, module version, and hash check values, which are used to ensure that the currently cached module cannot be tampered with. Hash is a string starting with h1:, indicating that the algorithm used to generate checksum is the first version of the hash algorithm (SHA256).

It is worth noting why some packages have only one line

<module> <version>/go.mod <hash>Copy the code

Some bags have two lines

<module> <version> <hash>
<module> <version>/go.mod <hash>Copy the code

For packages that have two lines, the difference is that the hash value is not one line. One is h1:hash and the other is go.mod h1:hash

H1 :hash and go.mod h1:hash either exist at the same time or only go.mod h1:hash exists. When there is no H1 :hash, Go omits the H1 hash when it decides that a module version is definitely not needed, and there is no H1 hash, just Go. Mod H1 :hash. [From 3]

Go. Mod and go. Sum are guidelines for the go Modules version management, so both files should be submitted to your Git repository to avoid other people using your project. The regenerated go.mod and go.sum are inconsistent with the base version you developed.

5. Use the go mod command

  • Go mod init: Initializes the go mod, generates the go.mod file, and then specifies the module name as shown above.

  • Go mod download: Manually trigger to download dependency packages to local cache (default: $GOPATH/ PKG /mod directory)

  • Go Mod Graph: Prints the module-dependent structure of the project

  • Go mod Tidy: Add missing packages and delete useless ones

  • Go mod verify: indicates whether the verification module has been tampered

  • Go Mod Why: Check why dependencies are needed

  • Go mod vendor: Export all project dependencies to the vendor

  • go mod edit: Edit the go.mod file, format the go.mod file with -fmt parameter, add a dependency with -require=golang.org/x/text, and delete a dependency with -droprequire=golang.org/x/textgo help mod edit

  • go list -m -json all: Prints dependency details as JSON

How do YOU add dependencies to your project (go. Mod)?

There are two ways:

  • You just have an import in your project, and then the Go Build will be downloaded and the Go Module will be added automatically.
  • Go. Mod will be automatically written after you manually download it using Go Get.

7. Write the summary at the end

If I had to evaluate GOPATH and Go Vendor in one paragraph, I would say

As the first package management mode of Golang, GOPATH can only guarantee that you can use it, but not guarantee that you can use it. Go Vendor solves the problem of GOPATH ignoring the package version, and it is guaranteed to be good, but not good enough, until the launch of go Mod, Only then did Golang package dependency management have a unified and satisfactory scheme for Gopher, and reached the standard that can be used and easy to use.

If you are just starting to learn Golang, GOPATH and Go Vendor can be properly understood without further study, unless the project you are going to take over is still using Go Vender for some historical reasons. In addition, Any Gopher should jump into go Modules right now.

The above is my study summary in these days, I hope to have no entry stage to you, help. In addition, if there is something wrong with this article, please criticize and correct it, so as not to mislead other friends. Thank you very much.

8. Recommended references

  • Dependency management for Go
  • The Go package relies on the management tool, Govendor
  • Go Modules The ultimate starter
  • Where to put our Go code

A series of reading

01. Setup of development environment (Goland & VS Code)

02. Learn five ways to create variables

03. Data type: **Integer and floating point **

Data types: byte, RUNe, and String

05. Data types: Array and slice

06. Data types: dictionary and Boolean

07. Data type: pointer

08. Object-oriented Programming: Structures and Inheritance

09. An article to understand the function in Go

10. Go language flow control: if-else conditional statements

11. Go language flow control: switch-case selection statement

12. Go language flow control: for loop statement

13. Go language flow control: GOto unconditional jump

14. Go language flow control: defer the call

15. Object-oriented programming: Interfaces and polymorphism

Key words: make and new difference?

17. An article to understand the blocks and scopes in Go

18. Learn Go coroutine: Goroutine

19. Learn Go coroutines: Detail channels/channels

20. Several classic error cases of channel deadlock

21. Learn the Go coroutine: WaitGroup

22. Learn Go coroutines: mutex and read-write locks

23. Exception handling in Go: Panic and recover

24. Super detailed interpretation of Go Modules past life and the introduction to use

25. Go language about package import must learn 8 knowledge points

26. How to open source your modules for others to use?

27. What about type assertions in Go?

28. These five points will help you understand the select usage of Go