为Python包编写需求/安装文件

Question

关于如何为您自己的python包选择所需包的版本，有什么最佳实践吗？

您可以始终执行pip freeze > requirements.txt，但这将将每个已使用的包设置为特定的版本。

如果这个包与另一个使用相同需求的包一起使用不同的特定版本，那么当anaconda、pip工具或诗歌试图找到依赖关系的正确组合时，您会遇到问题。

要让您的包与其他人一起工作，最好是让所选的版本尽可能宽，例如numpy>=1.20,<1.21。

对于整个包的要求，有什么好的方法可以这样做吗？

Answer 1

在库的打包元数据中(换句话说:在setup.py、setup.cfg或pyproject.toml中)，应该只列出直接依赖项。直接依赖项是由库的代码直接导入的依赖项(以及在子进程中调用的依赖项，但这是非常罕见的情况)。由于没有人能够预测未来，我关于依赖项的版本约束的建议是，只排除版本(或版本范围)，您可以100%地确定它们与库不兼容。

例如，我们正在处理MyLib v9，并希望添加一个SomeLib的依赖项，该依赖项只有v1和v2可用。我们想要的SomeLib的特性在v1中是不可用的，但是它们在v2上。我们不知道这些特性是否还会存在于SomeLib v3+中，因为我们无法预测未来。因此，在MyLib v9的打包元数据中，我们应该声明依赖项SomeLib>=2 (或SomeLib!=1)。

几个月后，SomeLib v3和SomeLib v4发布了，它们确实与我们的库兼容。我们不需要做任何事情，安装我们的MyLib的人将自动获得SomeLib的最新版本，这是v4，并且是兼容的。

几个月后，SomeLib v5发布了，它与我们的库不兼容。因此，我们应该发布MyLib v9.post1，在使用SomeLib>=2,<5 (或SomeLib!=1,!=5)打包元数据时调整依赖关系规范。

如果在发布不兼容的SomeLib v5时，我们都放弃了对MyLib的维护而不发布后期构建，那么MyLib的用户仍然能够手动地将有问题的SomeLib v5排除在依赖解析之外(例如使用a constraints.txt file)。这在Python打包生态系统中得到了很好的支持，非常容易做到。

另一方面，如果从一开始我们就急切地在最初的MyLib v9发行版中排除了除了MyLib v9之外的所有东西(可能是带有依赖关系规范(比如SomeLib==2) )，然后立即放弃了库的维护，那么就没有人能够用SomeLib v3 (或v4)安装我们的MyLib v9，即使它是一个非常有效的组合。这种过分明确的排他性现象是造成许多(无法解决的)问题的原因，这是一个近乎死胡同的问题，这确实应该避免。

这就是为什么，在我看来，依赖版本约束应该做的唯一事情就是排除众所周知的(和已证明的)不兼容。然后，尽可能发布"post build“版本，以便在出现新的不兼容性时改进版本约束。

参考资料

• https://caremad.io/posts/2013/07/setup-vs-requirement/
• https://peps.python.org/pep-0440/#post-release-separators
• https://pip.pypa.io/en/stable/user_guide/#constraints-files