我正在阅读文档，无法理解：
约束文件是仅控制已安装需求的版本，而不是是否已安装不它们的语法和内容与Requirements几乎相同文件。
有一个关键区别：在约束文件中包含包不会触发程序包的安装。
- 所以这是否意味着我需要先要求文件，然后运行约束
- 是否需要同时具有requirements.txt和constraints.txt
- 还是只是
-c requirements.txt
有人能用通俗易懂的英语解释一下新的PIP功能：约束文件的作用吗？
更新：pip 20.3于2020年11月30日发布，引入了一个新的解析器，修复了一些设计问题。它还重新实现了约束功能。现在很难或不可能按照我下面描述的方式使用该功能。我不了解新的约束实现，也不再使用它。我已经成功地使用了pip工具中的pip-compile。我在requirements.in中指定了顶级需求，pip-compile生成了一个具有特定版本和包散列的requirements.txt。有关工作示例，请参阅ichnaea项目中的requirements.in和requirements.txt。
下面的原始答案，适用于第20.2点和之前的
我认为约束文件是保持您的"；真"；要求与完整安装列表分开。
在需求文件中完全指定包版本是一种很好的做法。例如，如果您正在使用django LTS安装django-allauth，请将其固定到最新版本（截至我的回答）：
Django==1.8.12
django-allauth==0.25.2
当您安装软件包时，它最终也会安装一些所需的软件包。所以，你也可以添加这些，这样每个人都可以获得相同版本的包：
Django==1.8.12
django-allauth==0.25.2
oauthlib==1.0.3
python-openid==2.2.5
requests==2.9.1
requests-oauthlib==0.6.1
然后你得到错误报告"；在Python 3下不起作用；。Oops，python-openid仅为Python 2，而使用python3-openid，进一步需要defusedxml:
Django==1.8.12
django-allauth==0.25.2
oauthlib==1.0.3
python-openid==2.2.5 ; python_version < '3.0'
python3-openid==3.0.10 ; python_version >= '3.0'
defusedxml==0.4.1 ; python_version >= '3.0'
requests==2.9.1
requests-oauthlib==0.6.1
现在requirements.txt变得越来越难看，很难看到"要求"；Django和Django allauth在混乱中。
这里有一个requirements.txt，它引用了一个约束文件：
-c constraints.txt
Django==1.8.12
django-allauth==0.25.2
constraints.txt给出了一个有用的评论：
# django-allauth requirements
oauthlib==1.0.3
python-openid==2.2.5
python3-openid==3.0.10
defusedxml==0.4.1
requests==2.9.1
requests-oauthlib==0.6.1
不需要Python分类器，因为只有在包需要约束时才安装约束，否则将忽略约束。此外，如果一个软件包在2年后不再需要另一个程序包，则新安装的软件包将停止安装。
我认为这加上一些注释是一种很有用的方式，可以交流您在项目中使用的包，以及哪些包是包含的，因为它们是依赖项。
我认为，如果您使用pip8.x的哈希检查模式，它会变得更加有用，因为它需要指定依赖项的版本。如果你走上这条路，我推荐hashin来帮助你管理哈希。请参阅browsercompat，了解使用约束和散列的复杂需求设置。
来自《Python忍者的秘密食谱》一书
约束文件与需求文件有一个关键区别：将包放在约束文件中不会导致安装包，而需求文件将安装列出的所有包。约束文件只是控制将安装哪个版本的软件包的需求文件，但不提供对实际安装的控制。
假设您有requirements.txt文件，代码如下
# requirements.txt
pandas
和constraints.txt
# constraints.txt
# math / science / graph stuff
bokeh==0.11.1
numpy==1.10.4
pandas==0.17.1
scipy==0.17.0
openpyxl==2.3.3
patsy==0.4.1
matplotlib==1.5.1
ggplot==0.6.8
seaborn==0.7.0
scikit-learn==0.17
执行
pip install -c constraints.txt
将从requirements.txt安装所有软件包，并使用constraints.txt文件进行版本约束。
当您为生产环境提供用于生产基础设施的优化包编译时，约束文件非常有用。
我们在docker容器中提供numpy、scipy、tensorflow、opencv等版本的此类环境。。。针对我们的生产服务器进行了优化。为了确保开发人员为使环境可复制而设置的需求文件不会覆盖这些优化的安装，我们使用了约束文件。它们是作为构建过程的一部分编写的。pip通过设置PIP_CONSTRAINT环境变量来了解这些约束。
以前，开发人员总是必须确保他们的需求与prod容器中的可用内容一致，考虑到一些小版本号迭代得很快，这可能会很痛苦。
我自己没有使用约束文件，所以我可能错了，但以下是我从文档中理解它的方法。
比方说，您有多个使用pip安装的项目。它们中的一些直接依赖于流行的包foobar，一些间接地（通过依赖关系），一些根本不依赖它。
有一天，您决定稍微更改foobar代码，以解决与环境相关的一些问题，因此您可以继续创建foobar的本地副本。现在，您希望确保所有项目都使用此本地副本，但不想花时间弄清楚它们中的哪些依赖于foobar，然后编辑它们的requirements.txt或setup.py文件。
这里有一个constraints文件，您可以在其中指向foobar的本地副本，并将其用于所有项目，而不必关心其中哪个项目需要foobar，因为只有当正在安装的项目实际上依赖于foobar reddit上还有一个更好的可能用法示例。