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

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

但是,尤其是对于应用程序的最终用户来说,我严重怀疑大多数人是否喜欢搜索依赖关系。就拥有重复副本而言,我宁愿多花10毫秒下载额外的千字节,或者花一分钱在额外的兆磁盘空间上,也不愿花10多分钟搜索网站(可能已关闭)、下载、安装(如果版本不兼容,可能会失败)等。

我不在乎我的磁盘上有多少个图书馆的副本,只要它们不会相互妨碍。磁盘空间真的很便宜。

在将库/框架等与应用程序捆绑在一起的缺点中,一个重要的问题似乎被遗忘了:安全更新。

大多数Web框架都充满了安全漏洞,需要频繁修补。无论如何,任何库都可能因为安全漏洞而不得不升级。

如果你捆绑,系统管理员可能甚至不会 他们必须升级一些东西。

因此,捆绑的问题不在于磁盘空间,而在于让旧的和危险的副本四处传播的风险。

你不能只依赖这些依赖关系的某个版本吗?例如,在Python中 setuptools 您可以指定它需要的确切版本,甚至可以给出一些条件,如<=>等等当然,这只适用于Python和特定的包管理器,但我个人总是首先尽量不要捆绑所有东西。通过将其作为Python蛋发布,您还将自动安装所有依赖项。

当然,您也可以使用双向策略,只提供指向依赖项的链接来提供自己的包,但仍然以类似安装程序的方式提供完整的设置。但即便如此(在python的情况下),我建议简单地将鸡蛋与它捆绑在一起。

有关鸡蛋的介绍,请参阅 this post of mine .

当然,这是Python特有的,但我认为其他语言可能也有类似的打包工具。

如果你为最终用户生产软件,目标是让客户使用你的软件。任何阻碍都是适得其反的。如果他们必须自己下载依赖项,他们可能会决定避开你的软件。你无法控制库是否向后兼容,也不希望你的软件因为用户更新了系统而停止工作。同样,你也不希望客户安装带有旧库的旧版本软件,导致系统其余部分崩溃。

这意味着捆绑通常是可行的。如果你能确保你的软件在不捆绑依赖关系的情况下顺利安装,而且工作量更少,那么这可能是一个更好的选择。这是关于什么能让你的客户满意。

对于Linux,甚至不要考虑捆绑。你并不比包管理者或打包者聪明,每个发行版都有自己的方式——如果你试图走自己的路,他们不会高兴的。充其量,他们不会费心打包你的应用程序,这并不好。

请记住,在Linux中,依赖关系会自动为您拉入。这不是让用户得到它们的问题。它已经为你完成了。

对于窗户,请随意捆绑,你一个人在那里。

这只是我的经验,对此持保留态度。

我更喜欢我编写的几个开源库,因为它们尽可能独立于其他库。原因是,我不仅要与我的库一起分发其他库,而且还必须更新我的应用程序以确保兼容性,因为其他库也在更新。

从我使用的其他带有“公共”库依赖关系的库中,我总是需要在我的系统上使用多个版本的公共库。我使用的利基库的相对更新速度并不快,而普通库的更新频率要高得多。版本地狱。

但这只是泛泛而谈。如果我现在可以通过引入依赖关系来帮助我的项目和用户,我总是会考虑该决定的下游和后期影响。如果我能管理它,我可以自信地包括依赖性。

与往常一样,您的里程数可能会有所不同。