概括
我最近与我的一个应用程序所依赖的框架的创建者进行了对话。在那次谈话中,他顺便提到,如果我将他的框架与我的应用程序捆绑在一起,并向最终用户交付一个我知道与我的代码一致的版本,这将使我的生活更简单。直觉上,我一直试图避免这样做,事实上,我一直在努力分割自己的代码,以便在不占用整个项目的情况下重新分配部分代码(即使任何人都很少有机会重用任何代码)它)。然而,在考虑了一段时间之后,我无法想出一个特别好的理由来这样做。事实上,现在我已经考虑过了,我看到了一个非常有说服力的案例来捆绑我所有较小的依赖项。我已经列出了利弊清单,我希望有人能指出我遗漏的任何东西。
优点
- 版本的一致性意味着更容易测试和故障排除。
- 应用程序可能会覆盖更广泛的受众,因为要安装的组件似乎更少。
- 对依赖项的小调整可以更容易地在下游进行并与应用程序一起交付,而不是等待它们渗透到上游代码库中。
缺点
- 包含依赖项的更复杂的打包过程。
- 用户最终可能会在他们的机器上获得多个依赖项副本。
- 根据 bortzmeyer 的回应,无法升级单个组件存在潜在的安全问题。
笔记
作为参考,我的应用程序是用 Python 编写的,并且我引用的依赖项是“轻量级”的,我的意思是很小且不常用。(所以它们并不存在于所有机器上,甚至不存在于所有存储库中。)当我说“打包”我的应用程序时,我的意思是在我自己的源代码树下分发,而不是使用驻留在我的包内的脚本安装,所以会有不可能有冲突的版本。我也仅在 Linux 上进行开发,因此无需担心 Windows 安装问题。
话虽如此,我也有兴趣听到关于更广泛(与语言无关)打包依赖问题的任何想法。是我遗漏了什么,还是我只是想多了一个简单的决定?
附录 1
值得一提的是,我对下游打包者的需求也相当敏感。我希望尽可能简单地将应用程序包装在特定于发行版的 Deb 或 RPM 中。