开源软件 依赖_开源依赖管理是一种平衡行为

开源软件 依赖

在我的职业生涯中，我花费了大量时间打包其他人的代码，编写自己的代码，并使用大型软件框架。 我看到一些项目尚未发布稳定版本，从未达到1.0版本，而其他项目则在开始开发的几个月内发布了1.0版本，然后Swift发展到2.0、3.0等。这些版本存在很大差异。周期，再加上维护大型项目会使工作变得困难。

我将介绍我们在我从事的项目中面临的一些决定以及该项目的压力。 在一个极端情况下，用户希望拥有一个永不更改的稳定API，并且其依赖项未指定最低版本，以便他们可以选择最适合的版本。 另一个极端要求我们使用语言的最新功能，硬件加速的API，编译器以及我们依赖的库。

您应该在第一天使用这些软件，要求最新版本，还是给您的用户，发行版和其他用户时间更新？ 当有必要更改API时，您应立即更改它还是等待并批量更改为主要版本，并发出适当警告，从而减少API更改的频率？

开放化学与C ++ 11

当我们开始开发开放化学项目时，我们非常认真地考虑是否需要C ++ 11，当时我在社区中被许多人劝阻。 我们最终使用了C ++ 11的一些小部分，这些小部分可以成为可选的，而后退到Boost实现/空宏定义。 当时我认为这可能有点过于激进，但是如果我回去的话，我会告诉我以前的自我去争取。 该项目是新项目，现有用户很少，主要针对台式机。 此外，采用通常需要花费几年时间，而且支持较早的编译器也存在成本。

诸如Qt之类的几个主要项目在去年才刚刚开始要求C ++ 11，而更多的项目则需要+/-年。 我认为现在很明显，好处多于成本，但是需要非常新的编译器可能很难。 随着Microsoft发布具有完全C ++ 11支持的Visual Studio 2015社区版，并且Linux和Mac拥有良好支持的C ++ 11编译器已有一段时间，这变得更加容易。 Linux发行版的安全性和长期支持版本仍然在其中提出一些挑战，但是现在这在很大程度上已解决。

我已经将其余的依赖项与Visual Studio 2015一起使用（仍然是使依赖项正常运行的最困难的平台），并将很快删除可选的Boost回退代码。 现在还有其他明显的独特优势，例如PyBind11项目，该项目为C ++提供了仅标头的Python包装API，除了C ++ 11之外没有其他依赖项。 语言的更改也使某些本地实现不相关，并消除了使用线程，原子和其他新功能所需的复杂后备。 C ++ 14的问题仍然迫在眉睫，我很想直接跳到这个问题，因为看起来我们所有的平台现在都有很好的支持。 C ++ 14看起来更像是一个漏洞修复版本，但其中包含一些出色的修复程序！

第三方图书馆

作为花了很多年为Gentoo Linux打包软件的人，如果您在项目中捆绑了很多第三方库，我会骂你的名字。 作为软件开发人员，我完全可以理解为什么项目要这样做以及它如何使事情更容易启动和运行。 如果项目运作良好，开发人员将提出一个解决方案，该解决方案默认情况下会构建捆绑的库，并使打包程序和其他程序轻松使用系统库。

这依赖于上游库来维护稳定的API的第三方库，下游项目要遵循那些稳定的API以及要在下游项目中快速使用的常规发行版。 对于Linux发行版，理想情况下，应该只在一个或两个位置应用安全修复程序，然后在下次重新加载所有依赖项目时重新构建它们或将它们链接到更新的库。

当库中的API发生更改时，或者项目的开发人员不定期更新其第三方库时（或者在API更改时，会强制依赖关系进行更新），这将变得更加困难。 显然，理想的解决方案是使用具有定期发布周期的项目，以快速集成其新版本，并理想地维护一个稳定的API，该API在可以使用的库版本中提供一定的灵活性。

在Windows和Mac OS X平台上，在安装软件包后，很少会更新这些库，因此，跟踪上游并确保集成了任何安全修复程序显得尤为重要。 这样做具有挑战性，这也是我一直使用CMake的外部项目来构建依赖项的原因之一，该依赖项提供了将第三方库与更新版本的更简单集成捆绑在一起的许多优点。

OpenGL和科学可视化

我在近两年前撰写了一篇论文，讨论了可视化工具包（VTK）的渲染后端的重写 。 我认为重写早就该完成了，作为一个在加入Kitware之前写过渲染代码的人，我感到沮丧的是，我们不能使用OpenGL的最新进展（至少是过去十年中的某些进展）。 我知道我感兴趣的多个渲染工作负载可以从更新中受益，并且看起来这将是非常普遍的。

我已经开始研究如何进行一些增量更改，但是问题是OpenGL发生了很大变化，以至于很难。 其他人同意需要重写，但是认为重写所有渲染代码需要更多资金。 这是一项艰巨的任务，但到今天仍未完成。 虽然已经取得了长足的进步，但是总会有人们想要的新功能，优化功能以及为充分利用最新显卡而编写的渲染驱动程序的新部分。

我们将新的渲染后端称为OpenGL2，旧的主要是OpenGL 1.1，并在运行时检测到了新功能。 最初，我们的目标是台式机上的OpenGL 2.1和嵌入式系统上的OpenGL ES 2.0，这使OpenGL2感觉很贴切。 另外，从我的大量研究中，我发现很明显OpenGL 2.1和OpenGL ES 2.0具有许多其他项目使用的API的公共子集。 随着项目的发展，人们希望越来越多地使用OpenGL 3.2和OpenGL ES 3.0-新的最低要求。

我们在某些要部署到的系统/芯片上遇到了麻烦，并且软件渲染有时会遇到挑战。 总的来说，我们已经能够使事情变得可行。 它可以达到一个很好的平衡，并且可以清楚地确定哪些极端，但是中间立场常常最终变得很难定义。 太高的成本实在太高了，我认为VTK由于使用非常老的API而有被遗忘的危险，如果我们下周开始要求OpenGL 4.4，我们将遥遥无期在频谱的另一端。

Qt 3 vs.4 vs.5

在我的开发生涯中，我已经看到了Qt的三个主要版本，其中从3到4的过渡是最具挑战性的。 这些更新中的每一个都涉及相当大的更改，但在4到5过渡中所涉及的更改要少得多。 几年前，Avogadro 2项目更新到了Qt 5（它始于4，这是另一个案例，回想起来，我希望我们能早一点前进）。 在Tomviz项目中，我们重用了ParaView，并使用了Qt 4，直到大约一年前，那时我们已经完成了移至5的工作。

ParaView项目本身仍默认为Qt 4，在现代操作系统上支持Qt 4变得越来越困难。 他们都支持了一段时间，但仍然存在一些问题。 现代操作系统已取得重大进展，高分辨率显示和用户界面更新均导致与Qt 4目标的重大差异。

他们还对Qt与主机操作系统的集成方式以及与OpenGL交互的方式进行了重大更改。 此外，还需要对线程模型和更新进行重大更改，以利用C ++ 11和更高版本中的新功能，并且很难同时支持这两个主要版本。

Python 2与3

这让我彻夜难眠，几个项目不得不选择跳跃或跨越的方式，以便他们可以同时提供这两种方式。 在VTK项目中，我们的生成器代码必须进行更新，并且我们能够提供Python 2或3，但尚未投入工作来同时提供两者。 基于VTK构建的ParaView项目最近更新了其代码以支持Python 2和3，但是Python 3支持在那里仍处于试验阶段。 我希望在下一两个月内更新Tomviz以提供对Python 3的支持，并且随着越来越多的Python模块仅切换到Python 3，这一点变得越来越重要。

在网络方面，我从事了一个扩展Girder平台的项目，该平台本身使用CherryPy，PyMongo和许多其他模块。 当我们开始该项目时，它仅支持Python 2，但不久之后便增加了对Python 3的支持，使我们能够切换到Python3。由于这是一个新项目，我们决定不同时支持这两者，并且我们知道不太可能在短期内被广泛使用。 在Google Summer of Code指导者峰会上，Python社区中的一些人对此情况感到沮丧，并表示他们对支持这两者和放弃新语言功能的成本是否值得感到不满意。

总结思想

希望我们能够保持良好的中间立场，从而最好地为用户服务，并意识到过于保守或过于激进的代价。 大多数开发人员都渴望使用最新功能，而知道有一种更好的方法无法使用可能会非常沮丧。 我认为过于保守会付出巨大的代价，但我看到其他一些更新和更改过于激进的项目却失去了思想份额。

翻译自: https://opensource.com/article/16/11/open-source-dependency-management

开源软件 依赖