go语言 第三方包安装方法_跟我一起学习go语言,包依赖管理工具go mod

go语言 第三方包安装方法_跟我一起学习go语言,包依赖管理工具go mod_第1张图片

Go Module是Go会在1.12中正式推出的包管理机制。

Go mod 简介

Golang一直存在一个被人诟病的问题是缺少一个官方的包依赖管理工具。从我个人的角度上来看存在两个问题:

  1. GOPATH特性对于多工程的情况下,支持不算友好。
  2. GOPATH无法对依赖包进行有效的版本管理,没有任何地方能够表明依赖包的具体版本号,无法简单清晰获取到有效的依赖包版本信息等。

在Go1.11时,官方推出了go mod作为官方的依赖管理工具。而go mod与之前的利用vendor特性的依赖管理工具的不同点在于,go mod 更类似于maven这种本地缓存库的管理方式,不论你有多少个工程,只要你引用的依赖的版本是一致的,那么在本地就只会有一份依赖文件的存在。而vendor即使依赖的版本是相同的,但如果在不同的工程中进行了引用,也会在工程目录下的vendor产生一份依赖文件。

所以Golang在1.11版本中引入了go mod机制,在统一的位置对依赖进行管理。

go mod不同于以往基于GOPATH和Vendor的构建方式,其主要是通过GOPATH/pkg/mod下的缓存包来对工程进行构建。在Go 1.11中已经可以使用,同以往新添加的功能一样,go mod 可以通过GO111MODULE来控制是否启用,GO111MODULE有一下三种类型。

  • on 所有的构建,都使用Module机制
  • off 所有的构建,都不使用Module机制,而是使用GOPATH和Vendor
  • auto 在GOPATH下的工程,不使用Module机制,不在GOPATH下的工程使用

Go mod化处理步骤

这里我主要说一下,对旧工程如何进行go mod化处理。通过网上搜索的文档加上自我实践,我总结成了以下三个步骤。对于新工程的处理可直接从第二部分开始。

  • 将需要进行版本管理的代码从GOPATH路径下移出
  • 在项目的根目录下使用命令go mod init projectName
  • 在该目录下执行go build main.go

从GOPATH中移出工程

这一步其实是不一定需要的,不过个人认为可以将工程从GOPATH下移出,单独存放。只在GOPATH/pkg/mod目录下只存放依赖文件。

在go1.12环境下,我试验了一下环境变量GO111MODULE还是起作用的。但是编译时默认为使用Module机制进行编译(即GO111MODULE=on)。

  1. 如果工程中存在go.mod文件,编译时是从GOPATH/pkg/mod下查找依赖。
  2. 如果主动使用export GO111MODULE=off命令不使用Module机制,进行编译就会从GOPATH/src下查找依赖。会产生以下输出。(编译失败是由于相应目录下无依赖文件)

/usr/local/Cellar/go/1.12.5/libexec/src/golang.org/x/tools/internal/tool (from $GOROOT)

/Users/dx/go/src/golang.org/x/tools/internal/tool (from $GOPATH)

初始化go mod

在这一步根据我的实践,需要说一下。一般网上的资料都是建议在工程的根目录下执行go mod init projectName命令。在执行go mod化之后,所有的引用都不再是以GOPATH为相对路径的引用了,而是变成了以go.mod中初始化的项目名为起始的引用。

示例:

未使用go mod前,当前工程路径和GOPATH为workspace/testmod,即当前工程的结构如下:

├── bin

├── pkg

└── src

├── api

│ └── supply

│ └── location

│ └── location.go

└── main.go

location.go

package location

import (

"fmt"

)

func Hi(name string) string {

return fmt.Sprintf("hello %s

你可能感兴趣的:(go语言,第三方包安装方法)