更高版本ugo的一个功能,需要升级依赖。执行完dep ensure你会发现vendor中变化了,lock文件也变了
以上就是dep的简略介绍,我建议大家看一下 dep的运行机制 。里面提到了dep ensure这个命令,可以类比为函数的执行:toml和import就好比一个函数的输入,经过第一个函数resolving,输出的是lock文件,把其当做输入传入到第二个函数vendoring,输出的是vendor文件夹中的内容。这样有助于大家的理解,在本文没涉及到的情况,可以自己推理出来
模拟maven的一个方案
以下是我假象的,没经过验证的一个实际开发中的工作流程
首先,最好确保你的项目使用semver标准——语义化的版本标准,semver说明 ,这里规定了版本号代表的意思,比较,以及一些操作符。还规定最初版本从0.1.0开始(看到此一阵惊喜,我们组蒙对了)
然后,了解你依赖的代码,需要使用哪个版本。如果是自己团队的类库,遵守semver标准,利用git的tag功能来表示version, 比如打一个v0.1.0的标签
之后规规矩矩的按照go的要求新建一个项目,并且搞定版本控制。在ignore中写上 vendor/。这里我曾疑问,lock是否也可以排除?实际上可以,但官方文档曾经提到过"commit" lock文件
在项目根目录执行dep init。生成这三个东西。如果你可以copy一份toml过来,dep init完全不用执行,只要有toml文件,dep ensure完全可以生成其他两个
之后编码,涉及到远程依赖的内容,先在import中导入,再选择对应版本,在toml中修改,之后执行dep ensure
如果开发过程中需要升级,修改toml文件,再执行dep ensure
CI工具拉去到代码后,由于有toml文件,直接执行dep ensure就可以了,解决完依赖最后再执行go build
这么看起来似乎全局只有这一个命令是必须
注意,在我建议的方案中,toml文件要写成这样 version=“0.1.0”,不要再0.1.0前加等于号,为什么这样,你先最好了解了解go dep 的version rule
version rules
version rules在此,简单说,三位版本号第一位为major,跨major可以不兼容,后两位为minor和patch,必须保证在同一个major范围内向后兼容。说白了我以前用1.2.1版本,现在换成1.2.2或者1.3.1了,一定要没错误,但2.1.0不行(这就是咱们架构组的规则)
在dep中, =0.1.0代表确定这个版本, ^0.1.0代表 >=0.1.0 且 <1.0.0
[[constraint]]
name = "github.com/apodemakeles/ugo"
version = "0.1.0"
这种写法等价于^0.1.0,默认的一般是推荐的方案,为什么推荐这种呢?你可以理解,如果你按照semver的规范,没跨major的一定向后兼容,所以即使获取到0.1.1, 0.2.0,也不会出错。可为什么不能像maven一样固定一个坐标呢?
传递依赖
假设A依赖于B的一个功能(A,B是project, jar,或者dll),我们用A->B来表示,如果有A->B->C,则B对C为直接依赖,A对C为传递依赖。如果恰巧A->B->C且A->C呢,但这两个C又不是一个版本,会发生什么?
在node.js中并没有这种困扰,在依赖文件夹中会有两个C存在,然而对于C#,Java,Go这些语言,他们共同特点是current project下最终一个C只会有一个真实在磁盘上的产物,(dll, jar,带路径的.a),这时候就发生了依赖冲突问题
在C#的MSBuild中,随便选一个C(我感觉总是选高版本),生成dll,但在运行时,任何一个用到C.dll的dll,会检查当前依赖的版本范围内有没有C的版本,如果没有则在运行时出错
在Java的Maven中,会采用“最短路径”原则,此时A->C这条路径比较近,采用这条路径的pom中的版本。但这就又引来一个问题,如果这条短路径的C版本比较低,恰好B要用一个更高的C版本,因为里面有一个新方法,在运行时就会出错
那Go的dep呢?如果你在toml文件中这么写
[[constraint]]
name = "github.com/apodemakeles/B"
version = "=xxx"
[[constraint]]
name = "github.com/apodemakeles/C"
version = "=0.1.1"
此时不管B->C的版本比0.1.1高还是低(B->C也写为version="=x.x.x"),dep都不允许,都会报错,理由是“has no overlap”。如果B->C和A->C在一个major中,那就放开吧,直接写 verion="x.x.x"
这就是我推荐不带等号的原因
但有时候就是要确定某一个版本怎么办?可以使用toml中另一个约束override
[[constraint]]
name = "github.com/apodemakeles/B"
version = "=xxx"
[[override]]
name = "github.com/apodemakeles/C"
version = "=0.1.1"
这样会强制使用0.1.1的版本的C,但有可能出现上面maven同样的情况,需要你自己负责
零零散散的细节
截止到这里基本我觉得重要的内容就都说完了,toml和lock中还有很多内容没说,比如required,ignored,这些东西自己看就好。还有一些dep ensure的参数,比如-update,-add,我觉得大家不知道更好,可以统一使用规范,就只用dep ensure。而且官方也不建议把branch或者revision作为版本控制
- 如果你想要一个0.0.1版本的project,而服务器只有0.1.0以上的版本,即使使用范围比如^,~,也获取不到。我猜是因为dep把0.1.0作为最初始的版本
- dep status可以查看当前依赖信息
- dep ensure真挺慢