什么时候(不)适合将依赖项与应用程序捆绑在一起？

摘要

我最近与我的应用程序所依赖的框架的创建者进行了对话.在那次谈话中,他提到了一种说法,如果我将他的框架与我的应用程序捆绑在一起并将最终用户提供给我认为与我的代码一致的版本,那么它将使我的生活变得更简单.直觉上我一直试图避免这样做,事实上,我已经花了很多精力来分割我自己的代码,以便可以在不占用整个项目的情况下重新分配部分代码(即使很少有机会重复使用任何代码.它).然而,经过一段时间的考虑,我无法想出一个特别好的理由为什么我这样做.事实上,现在我已经考虑过了,我看到了一个非常引人注目的案例我所有较小的依赖项.我已经提出了一系列利弊,我希望有人可以指出我所遗漏的任何东西.

优点

版本的一致性意味着更容易进行测试和故障排除.

应用程序可能会覆盖更广泛的受众,因为安装的组件似乎更少.

对依赖项的小调整可以更容易地在下游进行,并随应用程序一起提供,而不是等待它们渗透到上游代码库中.

缺点

更复杂的打包过程包括依赖关系.

用户最终可能会在其计算机上拥有多个依赖关系副本.

根据bortzmeyer的回应,由于无法升级单个组件,因此存在潜在的安全问题.

笔记

作为参考,我的应用程序是用Python编写的,我所引用的依赖项是"轻量级",我的意思是小而不常用.(所以它们并不存在于所有机器上,甚至不存在于所有存储库中.)当我说"package with"我的应用程序时,我的意思是在我自己的源代码树下分发,而不是使用驻留在我的包中的脚本安装,所以会没有冲突版本的机会.我也只是在Linux上开发,所以不用担心Windows安装问题.

所有这些,我有兴趣听到有关包装依赖性更广泛(语言无关)问题的任何想法.有什么我想念的,或者这是一个简单的决定,我只是过度思考？

附录1

值得一提的是,我对下游包装商的需求也非常敏感.我希望尽可能简单地将应用程序包装在特定于发行版的Deb或RPM中.

我赞成捆绑依赖项,如果使用系统进行自动依赖解析(即setuptools)是不可行的,并且如果你可以在不引入版本冲突的情况下这样做.您仍然需要考虑您的申请和受众; 严肃的开发人员或爱好者更有可能希望使用特定(最新)版本的依赖项.捆绑东西可能会让他们烦恼,因为这不是他们所期望的.

但是,特别是对于应用程序的最终用户,我严重怀疑大多数人喜欢搜索依赖项.如果有重复的副​​本,我宁愿花费额外的10毫秒下载一些额外的千字节,或花费额外的磁盘空间的一分钱,而不是花费10多分钟搜索网站(可能会下来),下载,安装(如果版本不兼容可能会失败),等等.

我不在乎我的磁盘库有多少副本,只要它们没有互相帮助.磁盘空间确实非常便宜.