gomod是go的包管理工具,可以方便地管理依赖。减少git目录本身的容量,是一个很好的工具,但是在工程事件中出现一些疑惑,gomod到底该不该出现在通用包中呢。
下面是几点思考
支持通用包需要依赖的
通用包是对外提供能力的,因此需要确保逻辑本身是可用的。在通用包中定义的方法在特定的依赖版本上是经过测试可以正确正常执行的
例如:假设通用包是B,依赖通用包的是应用包C。B和C依赖了不同版本的A包
B依赖了1.0的A包方法a,C依赖了2.0的A包中的方法b。b是新方法,必须使用2.0的A包,但是2.0的A包更新了方法a的入参,导致方法a无法在B的逻辑中正确执行
不支持通用包需要依赖的
通用包提供依赖,导致应用包只要使用到通用包某方法就需要建立对通用包所有依赖的间接依赖,此时容易造成依赖的膨胀,以及因为某些间接依赖的版本造成应用包的方法需要更新/兼容
例如:假设通用包是B,依赖通用包的是应用包C。B依赖了A包和D包。C依赖了B,D包,但是其中B包相关的逻辑其实只涉及A包。此时还需要额外解决B中D包和C中D包的版本依赖问题
这没有一个最优解
我的想法是:
- 若通用包只是一些工具方法,依赖的是
encoding/json
,net/http
这种通用包,因为这类包通常完全前向兼容,应用包一般也会将这类包维持在较新版本,这种情况下通用包可以不设置gomod,有应用包的owner自身维护工程的正确性 - 若通用包提供了复杂业务逻辑的封装,依赖的是系统内的其他包。这种情况下无法保证其他包的更新是前向兼容的,因此需要将gomod作为依赖放置,使通用包始终维持自洽。若新接入的业务发现不兼容,可以去push通用包进行修改,及时暴露出问题
欢迎大家讨论