我正在阅读 文档,但无法理解它:
约束文件是只控制安装哪个版本的需求的需求文件,而不是是否安装它。它们的语法和内容与需求文件几乎相同。
有一个关键区别:在约束文件中包含包不会触发包的安装。
- 那么这是否意味着我需要先获取需求文件然后运行约束?
- 需要同时拥有 requirements.txt 和 constraints.txt?
- 或者只是
-c requirements.txt
?
有人可以用简单的英语解释一下新的 PIP 功能: Constraints Files 的作用吗?
原文由 James Lin 发布,翻译遵循 CC BY-SA 4.0 许可协议
更新: 2020 年 11 月 30 日发布的 pip 20.3 引入 了一个新的解析器,修复了一些设计问题。它还重新实现 了约束功能。现在很难或不可能按照我下面描述的方式使用该功能。我不了解新的约束实现,我不再使用它。我已经成功使用
pip-compile
来自 pip-tools 。我在requirements.in
中指定了顶级要求,并且pip-compile
生成了requirements.txt
具有特定版本的包哈希。有关工作示例,请参阅ichnaea
项目中的 requirements.in 和 requirements.txt 。下面的原始答案,适用于 pip 20.2 和以前的版本
我认为约束文件是将“真实”需求与完整安装列表分开的好方法。
在您的需求文件中完全指定包版本是一种 很好的做法。例如,如果您正在使用 Django LTS 安装 django-allauth ,请将其固定到最新版本(根据我的回答):
当您安装该软件包时,它最终也会安装一些必需的软件包。所以,你也添加它们,这样每个人都可以获得相同版本的包:
然后你会收到错误报告“在 Python 3 下不起作用”。哎呀,
python-openid
仅适用于 Python 2,而是使用python3-openid
,进一步要求defusedxml
:现在requirements.txt越来越丑了,乱七八糟的根本看不到Django和django-allauth的“requirements”。
这是一个
requirements.txt
指的是一个约束文件:和
constraints.txt
有一个有用的评论:不需要 Python 分类器,因为只有在包需要它们时才会安装约束,否则将被忽略。此外,如果一个软件包在 2 年后不再需要另一个软件包,则全新安装将停止安装它。
我认为这加上一些评论是一种有用的方式来传达您正在为项目使用哪些包,以及包含哪些包,因为它们是依赖项。
我认为如果您使用 pip 8.x 的 散列检查模式,它会变得更有用,它需要为依赖关系指定版本。如果你沿着这条路走下去,我推荐 hashin 来帮助你管理哈希。有关使用约束和哈希的复杂需求设置,请参阅 browsercompat 。