依赖管理学习

依赖管理&构建工具应该是什么样子的? github.com/vikyd/note/... todo: 生产环境中如何使用容器进行依赖的控制

语义化版本

术语

这个术语类似git tag, 不同之处在于, go提倡

java 复制代码

|-- module
|-- src // v0, v1
|-- v2 // v2 单独启一个路径, 下面放很可能不兼容v1的大修之后的代码(如果指定拉取v2版本，就会拉到这里)
    |-- src

总结下，go vendor其实就是为每个项目弄一个本地的依赖库，保证可复现的构建

go get无法满足可复现, 原因在于: go get每次都会从远程仓库拉最新的版本, 如果版本偷偷升级了, 其实构建出的就是依赖新版本的产物。

解决办法: snapshot, 基本哪里都有snapshot的身影, 原理就是把远程版本制作为本地依赖包, 然后设置为依赖本地的该包, 任由remote如何更新版本, 都不会影响本地(此时为远程的某个old version的快照)

但这个其实违背了 构建系统的细节应该不需要用户参与 这个原则, 用户切实的参与到了版本固定的过程...

所以下一步就是如何以用户无感的方式完成这种构建, 道理还是基于snapshot, 区别在于原本用户来做, 现在工具来做.

但是推进这个可复现构建的自动化的过程毕竟也是摸着石头过河, 由于没有明确的规范, 很多社区实现上定义了很多metadata, 包括在项目中使用项目特有的go vendor目录以及元数据。这些都不被go的官方识别。此时就是很混乱的阶段。

所以下一步就是官方出场, 定义规范，整合好用的社区版，杜绝群雄混战的问题。

就算是官方，也没法一次性直接把依赖管理从社区混战直接切换到最终稳定的工具，官方也需要推进一些临时性的工具，这些工具需要满足

灵活性和用户定制性的取舍: 官方需要考虑是设计一款makefile这样细节比较难以掌握, 但是构建过程可以让用户最大化定制这样的产品, 还是尽可能简洁, 用户不需要什么额外的学习成本的产品
集成工具链: 官方需要设计一款go toolchain里的一个命令, 直接在安装go toolkit的时候就能使用到这个依赖管理功能

官方的这个实践也称 go dep，但实际上最终的产品形态不是这个, 而是另一个项目vgo, go dep是依赖管理发展中的一个过渡.

import兼容性:

根据之前的规定(很多情况都是"官方没有明说, 但大家都遵守"), 如果一个依赖不跨大版本, 不管他有多少个小的feature version, 还是多少个bugfix version, import的形式都是一样的

go 复制代码

// e.g
// 对于这个import, some_module的版本可能是一个大版本下的任何版本
// 比如v1.1.1 v1.2.3 v1.11.4 v.1.114514.1919810
import example.com/some_module

当然，这个import兼容性其实主要是对 库的开发者来说的，如果我们在开发一个库，应该保证，如果我们要升级版本v1.1.0 到 v1.2.0，必须保证v1.2.0兼容v1.1.0

这个兼容性适用于什么case呢?

less 复制代码

A dep B 
A dep C

B dep D 1.1 // B使用了 import D
C dep D 1.2 // C使用了 import D

此时依赖管理工具可以放心的用D的1.1版本, 原因在于: 对于C而言，它使用的D1.2向下兼容D1.1

对于上面的论述，好像少了很多东西

实际上，这就是一种"约定大于xx"的理念, 如果我们是D的设计者，我们当然可以让D1.2不去兼容D1.1，那么可能日后的某一天，A这个项目的设计人员就会找到我们，说"你的设计不合理，导致我的项目出错"。所以这种约定其实是为了不给别人添加额外处理依赖的成本。

那如果D的新版本的确就不兼容旧版本呢? 此时如果都import D肯定不行, 此时就利用到了semver(语义版本)

less 复制代码

A dep B 
A dep C

B dep D 2.0 // B使用了 import D/v2 鲁迅
C dep D 1.2 // C使用了 import D 周树人(假设鲁迅和周树人不兼容)

此时依赖管理工具看到了，就可以认为: B依赖的是v2的D，而C依赖的是D，抓鲁迅和周树人没关系, 各自维护自己的依赖

但是还有一个问题，上面的约定还是比较严格的，哪怕一个小的版本升级，也可能带来不兼容性，比如D1.2也不兼容D1.1。

此时，与其把烂摊子留给用户来做, 比如在依赖管理工具上下点文章: 尽量延迟依赖的更新。不升级就不会出事，非必要不升级。而且如果真升出问题了，可能会在D的作者对应的仓库里存在对应的issue，D的作者也可能进行回滚，这样尽量减少了受影响面。

实现这一点的方法是: 最小版本选择

迁移到go mod后

todo: 日后更新