The dependency package management tool for Go has been released for a long time, and there are many articles about Go Modules, such as The Fish Fry: The Ultimate Beginner’s Guide to Go Modules.

In today’s post, I’d like to talk about some of the lessons we learned during the transition from Govendor to Go Modules, which might seem a bit trivial to you if you’re working on a project that already uses Go Modules.

Setting environment variables

GO111MODULE

This environment variable is used to switch on and off the Go Modules function. The default value is auto, which means that the Go Modules function is automatically enabled whenever the project contains the go.mod file. If you haven’t set this variable before, you can skip this step. When migrating to Go Modules from other package dependency management tools, you need to make sure that you have previously set GO111MODULE=off in the environment variable

GOPROXY

The default source site for the Go Modules to pull dependent software packages is https://proxy.golang.org. Due to a well-known problem, this domain name is restricted in China, so you need to use the GOPROXY environment variable to set the domestic mirror site.

GOPROXY=https://goproxy.cn
Copy the code

GOPRIVATE

This environment variable is intended primarily for some common internal software packages that the project depends on, and is typically set up as the domain name of the repository site. If all of our projects are in an internal code repository site built with GitLab, the domain name of this site is code.lazycorp.com, then we will set this environment variable to

GOPRIVATE=code.lazycorp.com
Copy the code

In this way, any module whose path prefix is code.lazycorp.com will not pull the package corresponding to the module through the mirror site specified by GOPROXY, and will go to code.lazycorp.com to pull the package.

As a tip, if you don’t want to pollute global environment variables in your computer when developing, you can choose to enable Go Modules support and set environment variables in GoLand, so that you can use Go Modules when compiling and running applications in GoLand.

Replace Completes the version replacement

The replace directive replaces the required module version with a module version in the go.mod file, for example:

module code.lazycorp.com/buzz/practice // I made this name up in a blind

go 1.13

replace(
  google.golang.org/grpc v133.. 0 => google.golang.org/grpc v126.. 0
)

require (
	google.golang.org/grpc v133.. 0
)
Copy the code

The replace directive identifies the v1.33.0 version declared in require as v1.26.0 of GRPC.

However, it also happens that the replace command can solve several software package version compatibility issues. The software package compatibility issues I encountered were mainly on Etcd and gRPC.

IO /bbolt, but their own source code using this library in the code using the import path is github.com/coreos/bbolt. In addition, the software package provided by Etcd is not compatible with the V1.33 VERSION of gRPC. Therefore, if the gRPC uses Etcd Naming for service discovery and load balancing, the two modules can only be replaced by the replace command.

replace (
	github.com/coreos/bbolt => go.etcd.io/bbolt v13.. 5
	google.golang.org/grpc v133.. 0 => google.golang.org/grpc v126.. 0
)
Copy the code

Versioning of modules

The module version number corresponds to the package’s tag, for example, the module above references google.golang.org/grpc v1.26.0 to the GRPC’s GitHub repository tag named V.1.26.0.

Note That the label name is not arbitrary, for example, v2020…. The Go Modules tag is unrecognizable.

The Go Modules version format is “Major version number. Minor version number. Revision number. The increment rule of the version number is as follows:

V1.26.0 | | | _ _ revision | | | | _ _ _ _ a version number | | _ _ _ _ _ the major version numberCopy the code
  1. Major version number: Change the major version number when you make incompatible updates.
  2. Minor version number: Change the minor version number when you make a backward-compatible functional update.
  3. Revision number: Change the revision number when you make a backward-compatible problem patch fix.

Module versioning in test and production phases

If we make changes to the company’s public package, how do we label the public package? You don’t have to label software packages with different versions during test, simulation, and production, which can be confusing to manage in the code repository.

In this case, you can append the version information to the major version number. Second version number. Revision number “, as an extension, e.g.

// Label the test branch v1.2.30-test // Label the simulation branch v1.2.30-preCopy the code

This way, when the test passes and a project referencing a public package needs to go live, you can tag it with v1.2.30 in the master branch of the public package and change the reference in the go.mod file to the official version.

In addition, if there are no tags in the repository of the common package, go Get by default pulls the code corresponding to the last commit of the trunk branch, and allocates a virtual version of the module in the go.mod file in the format of v0.0.0- the time of the last commit of the trunk branch -commit hash.

Common Commands

  • go mod initInitialize thego.modFile, usually used when creating a new project.
  • go mod tidySort out existing dependencies and modify themgo.modPost-file execution updates dependencies.
  • Go Mod Graph looks at existing dependency structures.
  • go mod vendorExport all project dependencies tovendorDirectory (Not recommended).

The go Mod vendor command is listed here to remind you that if you use go Mod Vendor, you will generate a vendor directory in your project and put all the dependency exports into it. Then Go Modules in the project will Go to vendor to find the referenced dependency package instead of the default $GOPATH/ PKG /mod directory.

If we actively update the dependency package, we need to run go mod vendor again to export the update to the vendor directory so that the project can actually reference the updated dependency package.

Therefore, since you start to use Go Modules, you should try to forget vendor. In addition, the first step of the old project when switching from Govendor to Go Modules is to delete the vendor directory in the project, and then migrate according to the steps in the article.

If you like my article, please give me a thumbs up. I will share what I have learned and seen and first-hand experience through technical articles every week. Thank you for your support. Wechat search concerns the public number “network management talking BI talking” every week to teach you an advanced knowledge, there are special for the development of engineers Kubernetes tutorial.