我使用pip和virtualenv来打包和安装一些python库。

我可以想象我正在做的是一个非常常见的场景。我是几个库的维护者，我可以为这些库显式地指定依赖项。我的一些库依赖于第三方库，这些库具有我无法控制的可传递依赖项。

我正在尝试实现的是让我的某个库上的pip install下载/安装其所有上游依赖项。在PIP文档中，我正在努力解决的是需求文件是否能够独立完成这些工作，或者它们实际上只是使用install_requires的补充。

我会在所有库中使用install_requires来指定依赖项和版本范围，然后只使用需求文件来解决冲突和/或冻结它们进行生产构建吗？

让我们假设我生活在一个虚构的世界(我知道，我知道)，我的上游依赖是直接的，并且保证永远不会冲突或破坏向后兼容性。我到底是被迫使用一个PIP需求文件，还是仅仅让PIP/SETUPTOOLS/Distribute根据install_requires安装所有内容？

在这里有很多类似的问题，但我找不到任何一个像什么时候使用一个或另一个或同时使用它们一样基本的问题。

我的哲学是，install_requires应该表示你所需要的最小值。如果您知道某些版本不起作用，它可能会包含版本要求；但是在您不确定的地方，它不应该有版本要求(例如，您不确定将来的依赖项版本是否会破坏您的库)。

另一方面，需求文件应该指出您所知道的功能，并且可能包括您建议的可选依赖项。例如，您可以使用sqlacalchemy，但建议使用mysql，因此将mysqldb放在需求文件中)。

所以，总而言之：install_requires是让人们远离你知道不工作的事情，而需求文件则是引导人们去做你知道工作的事情。其中一个原因是，总是检查install_requires需求，如果不实际更改包元数据，则无法禁用该需求。所以你不能轻易尝试新的组合。仅在安装时检查需求文件。

以下是我在setup.py中的内容：

python packaging用户指南中有一个关于此主题的页面，我强烈建议您阅读：

• 安装需要vs需求文件

总结：

install_requires中列出了必须安装包才能使包工作的包的依赖项。它并不打算将依赖项固定到特定的版本，而是接受范围，例如install_requires=['django>=1.8']。install_requires由pip install name-on-pypi等工具观察。

requirements.txt只是一个文本文件，您可以选择对其运行pip install -r requirements.txt。它的目的是固定所有依赖项和子依赖项的版本，如：django==1.8.1。您可以使用pip freeze > requirements.txt创建一个。(有些服务，如Heroku，自动为您运行pip install -r requirements.txt。pip install name-on-pypi不看requirements.txt，只看install_requires。

我只使用过setup.py和install_requires，因为只有一个地方可以看。它就像拥有一个需求文件一样强大，并且没有需要维护的重复。