Python packaging：指定外部需求的不同方法——差异、优势和建议

Question

我正在打包一个 python 项目并寻找 "right" 指定外部文件依赖项的方法。我知道有多种指定依赖关系的方法，但我想知道这些方法在实际中是如何工作的，它们有何不同，以及它们分别在哪些具体时间点生效。

指定依赖关系的已知方法（参见here）

1. 我们可以在 setuptools.setup
的 install_requires 参数中指定依赖关系
2. 我们可以使用 requirements.txt
3. 我们可以使用 setup.cfg

我的主要问题

1. 不同方法的优缺点是什么？
2. 何时以及以何种顺序读取各个文件中的信息？会例如pip 首先执行 setup.py 之后检查 requirements.txt?
3. 如果我仅以上述方式之一指定要求，会发生什么情况？如果我用不同的方式指定不同的要求，会发生什么情况？

励志例子

我需要创建一个使用 cython 和 numpy 的包。可以看出，例如、cython（和 numpy 类似，必须在调用 setuptools.setup 之前导入。因此，如果库 setup.py 会引发 ImportError不可用。无论如何，我如何使需求可见，以便在 之前安装必要的包 setup.py 被调用？我应该将编译移动到另一个文件吗？从 setup.py 呼叫？我该怎么做？

Answer 1

这些是很多宽泛的问题。很难给出详尽的答案并保留意见...

---

说到严格打包Python项目，我相信pip的“requirements”文件并不常见useful nor used（当然有反例，但我认为它们通常不是包装的好主意）。但在其他一些用例中，我相信它们非常有帮助。

如果setuptools用于打包（有完全有效的替代方案），那么install_requires是声明项目直接依赖的方式。除非没有其他办法，否则我建议将整个 setuptools 配置（包括 install_requires）放在 setup.cfg 文件中，而不是作为 setup.cfg 的参数=13=]。在这两种情况下，结果将完全相同，但是（因为现在普遍接受）对于配置，静态声明文件比可执行代码更自然。至于优先顺序，我相信 setuptools.setup() 参数会覆盖从 setup.cfg.

读取的相同配置项

Would e.g. pip first execute setup.py and then check the requirements.txt afterwards?

这是两个不同的东西。 requirements 文件或多或少是一个要安装的项目列表。这些项目中的每一个都可能以不同的方式打包（setuptools 或其他）和分发（源代码或预构建 wheel），有些将需要执行 setup.py 有些人不会。但是同样，当打包（和分发）一个项目时，通常不需要理会 requirements 文件（当项目是一个库时从不，当项目是一个应用程序，请参阅 Donald Stufft's article "setup.py vs requirements.txt")。

关于 Cython 和 setuptools 组合的问题，我不想详细讨论。这将是一个很好的附加问题。不过，这两个链接可能会帮助您入门：

• https://setuptools.readthedocs.io/en/latest/setuptools.html#distributing-extensions-compiled-with-cython
• https://medium.com/@grassfedcode/pep-517-and-518-in-plain-english-47208ca8b7a6