如何在升级 Python PIP 包时识别重大更改？ [关闭]

Question

我正在使用 PIP 升级项目中的 Python 包。项目启动以来，在多个依赖项中进行了多次版本升级。假设我想将一个名为

X

的 PIP 包升级到更高版本，那么我如何识别所有依赖 PIP 包中的所有重大更改，以便我可以评估升级包

X

的风险与回报？

Answer 1

升级 ... X ... 我如何识别所有重大变化

评估风险与回报

zomg，还有很多事情没有说！

从某种意义上说，“破坏”是微不足道的。 Pin X at 2.3.0，安装成功， 然后将其固定在 2.4.0 并查看

$?

从

pip install

退出状态，看看它是否坏了。 即查看其他{Y,Z}包 您要求的与 2.4.0.

不兼容

但我们不知道您是否指定 必须安装包 X、Y、Z

==

一个特定的固定版本，或者如果你是 允许任何

>=

更新版本，或者如果 你只承认补丁级别的升级。 这三个包有自己的部门，其中 可传递地有部门，他们相互作用。 可以 try 预测

pip

会做什么， 但有什么意义呢，因为那个算法 无论如何都会在几个月内恢复。

只需尝试您提出的

pip install

沙箱并完成它。它有效或无效。 如果它不起作用，请不要将更改投入生产。

“破变”的另一种解读 是 pip 拉入了一些图书馆吗 破碎的w.r.t.到您的应用程序，也许是因为您的 应用程序依赖于越野车行为并且被 最近推出的错误修正。 那种东西只能被检测到 你的测试设置，但你什么也没告诉我们 您的自动化+手动测试。所以我们又 留下“试试看！”，把它放进去 只有在 QA 批准后才能生产。

即便如此，你可能还想金丝雀一段时间， 所以只有 1% 的生产用户看到新配置， 如果没有抱怨，那么他们会更多， 也许一天后所有用户都使用相同的配置。 这对于一个团队来说可能是有效的 擅长记录你关心的KPI， 并快速解析这些日志， 并迅速将最终用户的电话/电子邮件带到 技术人员的关注。

---

一般有两种情况：

1. 您的应用对库很满意，它们应该保持冻结状态。
2. 您的应用需要错误修复或新库。

在第二种情况下，您可以，理论上，只接受 X 中的新错误修复或添加一些新库。 但是你将不得不做

pip install

和单位和系统 无论如何都要进行测试，所以您也可以（尝试）升级另一个 当时的包也。为什么？所以你使用的是现代版本 上游作者也测试过的组合，而不是 这个是新的，那个是古老的疯狂组合。 如果 uprev 尝试失败，显示不兼容， 让它发挥“我们应该 是否接受错误修复/新库？”

Answer 2

在理想世界中，语义版本控制将是一个很好的解决方案。但众所周知，语义版本控制几乎不可能始终保持 100% 准确，因此总是有机会发布 minor 更新，其中确实包含针对某人用例的重大更改。

如果我是你，我会做的（我想其他人也会这样做，这不是秘密）是构建和维护最完整的测试套件，并提供准确的覆盖率监控。这可以帮助检测依赖项中的重大更改。但当然它也不是防弹的，总有可能遗漏一些你从未想过的测试用例。

在某种程度上，类型提示也可能有助于发现 API 中的重大变化。