如何处理依赖的多个主要版本答案

【问题标题】：How to handle multiple major versions of dependency如何处理依赖的多个主要版本
【发布时间】：2019-08-26 10:15:51
【问题描述】：

我想知道如何处理依赖库的多个主要版本。

我有一个开源库Foo，处于早期发布阶段。该库是另一个开源库Bar 的包装器。 Bar 刚刚推出了一个新的主要版本。 Foo 目前只支持之前的版本。由于我猜测很多人从Bar 之前的主要版本转换到新的主要版本会很慢，所以我不愿意自己切换到新版本。

如何最好地处理？在我看来，我有这些选择

切换到新的主要版本，可能会拒绝使用旧版本的人。
继续使用旧版本，可能会拒绝人们使用新版本。
有两个不同的分支，为所有新功能更新两个分支。不确定这如何与 PyPi 一起使用。我不是每次都必须以不同的版本号发布吗？
将存储库分成两部分。真的不想这样做。

对我来说理想的解决方案是拥有相同的代码库，我可以在其中拥有某种类似 C/C++ 宏的东西，如果版本是 new，则使用 new_bar_function，否则使用 old_bar_function .从 PyPi 安装库时，主要版本的已安装版本指示使用哪个版本。如果未安装任何版本，请安装最新版本。

不胜感激。

【问题讨论】：

标签： python pip dependencies wrapper pypi

【解决方案1】：

通常使用package.__version__ 导入后，包版本信息可用。您可以从 Bar 解析该信息并根据此决定做什么（选择适当的函数调用或停止程序或引发错误或...）。

您还可以从https://www.python.org/dev/peps/pep-0518/ 获得一些关于控制依赖项安装的方法。

似乎如果有人已经安装了Bar，安装Foo 只会更新Bar，如果Foo 明确需要新版本。见https://github.com/pypa/pip/pull/4500 和这个answer

【讨论】：

这可行。但这不是坏习惯吗？我认为我以前从未见过在源代码中使用过它。通常仅在 init 或设置文件中。
你完全可以在init文件中定义函数来实现“...如果版本是new，使用new_bar_function，否则使用old_bar_function。 "通过将适合的那个分配给bar_function，然后使用bar_function。话虽如此，我同意@di 的观点，即如果不讨论设计选择和具体情况，很难判断应该采用哪种方法。即函数在输入/输出方面的行为是否不同？只有一个功能还是您必须更改Foo 的大部分内容才能从一个版本转到另一个版本（双向）？
我将此标记为正确，因为它在技术上是我正在寻找的解决方案。我最终意识到我可以通过稍微聪明一点来绕过纯代码的差异，而无需版本控制。因此，我可以同时支持这两个版本，因为我的包装库只涉及核心，而不涉及新功能。但是感谢你们俩的好答案。

【解决方案2】：

有两个不同的分支，为所有新功能更新两个分支。不确定这如何与 PyPI 一起使用。我不是每次都必须以不同的版本号发布吗？

是的，您可以同时发布 1.x 版本（支持旧版本）和 2.x 版本（支持新版本）并同时发布这两个版本。对于想要引入重大更改但仍希望继续维护先前版本的软件包来说，这是一种常见的模式。

【讨论】：

即使库主要版本之间的更改不一定会影响我的库？
我认为如果它影响到使用您的图书馆的用户，那将是合适的，但如果没有更多信息就很难说。
我遇到了和 OP 一样的情况。虽然我会首先尝试@fabianegli 的答案作为快速破解，但这里的“将 Foo 拆分为 1.x 和 2.x 分支”主题导致了一个通用的实现：当我的 LIBRARY Foo 1.x 对库 @ 有内部依赖时987654322@，即使Foo 没有直接在其 API 表面公开old_bar_function()，它仍然有一个隐式公开（或者我们甚至可以称之为要求）在当前环境/命名空间中固定bar.old_bar_function()。因此，只需将依赖项升级到Bar 2.x 就可以证明Foo 上的主要版本提升是合理的。是的？没有？