python - 如何防止 Pypi 软件包维护者决定删除软件包？

Question

似乎可以删除 Pypi 的软件包(或软件包版本): How to remove a package from Pypi

如果您已经完成了某些软件的开发并希望在构建时能够从 Pypi 中提取依赖项，这可能会成为问题。

防止这种情况的最佳做法是什么？

Answer 1

Unnecessary_intro=<< SKIP_HERE

事实上，这是一个比仅仅阻止另一个 leftpad 实例更深层次的问题。一般来说，依赖关系管理的实践是由通常是隐含的社区规范定义的。从这个意义上说，Python 尤其糟糕，因为它不仅隐含了这些规范，而且它的包管理工具也是建立在不保证依赖兼容性的前提下的。自从 PyPI 出现以来，两个包安装程序都不能保证安装兼容版本的依赖项。如果包 A 需要包 B==1.0 和 C==1.0，而 C 需要包 B==0.8，那么在安装 A 后，您可能最终会得到 B==0.8，即 A 依赖关系不会得到满足。

SKIP_HERE

0。明智地选择，使用信号。

开发人员和软件包维护人员都意识到了这种情况。人们试图通过选择“好的”项目来最大程度地减少这种破坏的可能性，即拥有一个健康的社区，其中一个人不太可能做出此类决定，并且能够在不太可能发生的情况下恢复项目。

这些信号的设计和评估是一个活跃的研究领域。最常用的因素是包贡献者的数量(总线因素)、健康实践(测试、CI、文档质量)、GitHub 上的 fork 数量、星星等。

1。将包代码复制到源代码树下

如果您不希望包发生很大变化，但又担心包被删除或发生重大更改，这是最简单的情况。它还为您提供了根据您的需求定制软件包的优势；另一方面，现在的软件包更新将需要相当多的努力。

2。在 PyPI 上重新发布包的副本

我不记得确切的名称，但其他开发人员以不同的名称重新发布了一些引人注目的软件包。在这种情况下，您所需要的只是复制包文件并重新发布，这可能比在源代码树下维护副本便宜。不过，它看起来很脏，我不鼓励这样做。

3。私有(private) PyPI 镜像

#2 的更干净但更昂贵的版本。

4。另一层抽象

有些人选择了一些竞争性的替代方案，并在它们的基础上创建了一个抽象，能够使用不同的“后端”。这样做的原因通常是不应对可能的包删除，并且根据接口(interface)的复杂性，它可能会非常昂贵。这种抽象的一个例子是 Keras，它是一种神经网络抽象，它为 tensorflow 和 theano 后端提供了一致的接口(interface)

5。还有更多选择

更奇特的选项包括分发虚拟环境/容器/VM 的快照、重新实现 packagegage(特别是由于许可问题)等。