姜戈：requirements.txt

Question

到目前为止我知道 requirements.txt 是这样的：Django==2.0。现在才看到这种文风Django>=1.8,<2.1.99

你能给我解释一下这是什么意思吗？

Answer 1

requirements.txt 是一个指定 dependencies 的文件。例如，您的程序将在这里依赖于 Django（您可能不想自己实现 Django）。

如果只编写自定义应用程序，而不打算将其导出（例如作为库）给其他程序员，则可以固定库的版本，例如 Django==2.0.1。然后你总是可以假设（假设 pip 设法安装了正确的包）你的环境将有正确的版本，因此如果你遵循正确的文档，就不会有问题（好吧应该 ) 出现。

如果您实现了一个库，例如 mygreatdjangolibrary，那么您可能不想固定版本：这意味着每个想要使用您的库的人都必须安装 Django==2.0.1.想象一下，他们想要一个仅在 django-2.1 中可用的功能，那么他们可以——假设他们严格遵守依赖关系——不这样做：你的库需要 2.0.1。这当然不好管。

因此，通常在图书馆中，人们的目标是为图书馆的用户提供尽可能多的自由。如果无论用户安装的 Django 版本如何，您的库都可以工作，那将是理想的。

不幸的是，这会给库开发人员带来很多麻烦。想象一下，您必须考虑到用户最多可以使用 Django-1.1 django-2.1。多年来，已经引入了几个库不能使用的功能，因为程序员应该保守，并考虑到用户安装的库中可能不存在这些功能。

由于 Django 进行了一些重构，情况变得更糟：一些功能后来被删除，所以我们不能简单地在 django-1.1 上编程并希望一切顺利。

因此，在这种情况下，指定我们支持的范围版本是有意义的。例如，我们可以阅读 django-2.0 的文档，并查看发行说明以查看 django-2.1 中是否有相关更改，然后让 tox 测试两者我们编写的测试版本。因此，我们可以指定一个范围，如 Django>=2.0,<2.1.99.

如果您依赖多个库，每个库都有共同需求，这也很重要。比如说你想安装一个库 liba 和一个库 libb，两者都依赖于 Django，但两者有不同的范围，例如：

liba:
    Django>=1.10, <2.1
libb:
    Django>=1.9, <1.11

那么这意味着我们只能安装>=1.10和<1.11之间的Django版本。

以上甚至很容易变得更复杂。由于liba和libb当然也有版本，例如：

liba-0.1:
    Django>=1.10, <2.1
liba-0.2:
    Django>=1.11, <2.1
liba-0.3:
    Django>=1.11, <2.2

libb-0.1:
    Django>=1.5, <1.8
libb-0.2:
    Django>=1.10, <2.0

因此，如果我们现在要安装 liba 和 libb，我们需要找到 liba 和 libb 的版本 "allows" 我们安装一个 Django 版本，这不是那么简单，因为例如如果我们选择 libb-0.1，那么就没有支持 "overlapping" 的 liba 版本Django 版本。

据我所知，pip 目前没有依赖项解析算法。它查看规范，每次都旨在选择满足约束的最新的，并递归安装这些包的依赖项。

因此，由用户确保（子）依赖项不冲突：如果我们指定 liba libb==0.1，那么 pip 可能会安装 Django-2.1，然后发现libb不能用这个。

有一些依赖关系解析程序。但事实证明这个问题相当困难（如果我没记错的话是NP-hard）。因此，这意味着对于给定的依赖关系树，可能需要数年时间才能找到有效的配置。

姜戈：requirements.txt

Django: requirements.txt

python

django

requirements.txt