0%
现象
- 例如: libA 依赖 libX@v1, libB 依赖 libX@v2, v1和v2不兼容
- 最好是不同的库能独立使用自己的依赖, 有需要再决断使用一个, 但大部分比较老的语言都不支持
- 最近在写不同的项目时, 发现它们对同名不同版本的依赖处理方式不一样, 这里大概列下, 方便使用不同的方案
可以打包两个版本的依赖进去的
- 以rust的包管理器cargo为例
- 发生这种依赖的时候, cargo首先会决策是否可以使用用一个版本, 例如 1.2.4 和 1.2.* 就是可以兼容的
- 可以兼容时, 就使用一个版本
- 当不能兼容时, 就会把两个版本都打包进二进制中去
- 这时候使用name mangling来保证符号不一样, 不冲突
- 但这时候, 两个版本中同名的类也被认为是不同的类型, 不能互相传递
- 类似的还有
- js的npm
- go比较特殊, 默认使用高版本, 但也支持打包两个版本到一个库中去, 通过replace依赖名实现
只能打包一个版本的
- c++: 最复杂, 涉及到静态/动态库的绑定, 问题最多
- Python(pipenv): 会抛出依赖报错, 需要对有问题的库强制指定版本, 覆盖后面的间接依赖
- java(mvn/gradle): 通过配置调整, 忽略掉一些间接依赖, 排除一些库
- c#: 通过配置忽略, 类似java