[ 003.GO语言依赖管理演进 | 青训营笔记 ]

133 阅读3分钟

前言

Go依赖管理经历了3个阶段:

  • 早期GOPATH
  • 中期Go Vendor
  • 最新Go Module

目前被广泛应用的是 Go Module,整个演进路线主要围绕实现两个目标来迭代发展:

  • 在不同环境 (项目) 依赖的库的版本不同
  • 控制并管理依赖库的版本

早期GOPATH

GOPATH 是一个环境变量,用来表明你写的 go 项目的存放路径,GOPATH 路径最好只设置一个,所有的项目代码都放到 GOPATH 的 src 目录下。

windows下环境配置内容:

系统变量GOPATH:D:\CODEFile01\GoPro path添加路径:go编译器路径 和 GOPATH对应文件夹路径 在GOPATH目录下新建三个文件:

  • bin:用来存放编译后生成的可执行文件
  • pkg:用来存放编译后生成的归档文件
  • src:用来存放源码文件

在进行Go语言开发的时候,我们的代码总是会保存在GOPATH/src目录下。在工程经过gobuildgoinstallgoget等指令后,会将下载的第三方包源代码文件放在GOPATH/src目录下。在工程经过go build、go install或go get等指令后,会将下载的第三方包源代码文件放在GOPATH/src目录下, 产生的二进制可执行文件放在GOPATH/bin目录下,生成的中间缓存文件会被保存在GOPATH/bin目录下,生成的中间缓存文件会被保存在GOPATH/pkg 下。

编写的代码在src目录下,并且go get进行下载的包也会放在src目录下,这样存在一个问题:

- 项目A 和项B 依赖于某一 package 的不同版本 (分别为 `Package V1``Package V2` ) 。而 `src` 下只能允许一个版本存在,那项目A 和项B 就无法保证都能编译通过。
- 在 GOPATH 管理模式下,如果多个项目依赖同一个库,则依赖该库是同一份代码,无法做到不同项目依赖同一个库的不同版本。

中期Go Vender

面对早期GOPATH的依赖管理方式存在的弊端出现了Go Vendor的解决方案。

早期GOPATH依赖管理的项目结构:

  • 环境变量GOPATH指定文件夹路径
  • 手动创建 bin/ 、pkg/ 、src/ 三个文件夹 1 2 中期Go Vendor依赖管理的项目结构:

环境变量GOPATH指定文件夹路径 手动创建 bin/ 、pkg/ 、src/ 三个文件夹 新增vendor文件 vendor文件其实是一个目录,所在的该项目使用依赖包会以副本形式放在vendor目录下。这个时候,导入包会引入优先级:

  • 当前项目存在 Vendor 目录,会优先使用该目录下的依赖
  • 如果依赖不存在,则会从 GOPATH 中寻找 1 2 看到这里,因该会明白了与早期GOPATH管理方式的不同之处。

缺点产生:

  • Vendor 无法很好解决依赖包版本变动问题和一个项目依赖同一个包的不同版本的问题。
  • 项目A依赖项目B与项目C,项目B依赖项目D-V1,项目C依赖项目D-V2,这样底层同一个项目A底层依赖了同一个项目D的不同版本

最新Go Module

Go Module 自 Go1.11 开始引入,Go 1.16 默认开启。可以在项目目录下看到 go.mod 文件。

Go Module实现依赖管理三个要素:

  • 配置文件go.mod用于描述依赖
  • 代理Proxy实现中心仓库管理依赖库
  • go mod 操作命令用于管理依赖库初始化、更新 1 2 3 module test // 依赖管理基本单元

go 1.18 // 原生库依赖原生的Go SDK版本

require ( // 单元依赖 标识命名:module路径 + 版本号 rsc.io/quote v1.5.2 golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c // indirect rsc.io/sampler v1.3.0 // indirect )

文章部分内容来源于:blog.csdn.net/weixin_4352…