Python 打包中的依赖关系是一个令人困惑的主题。长期以来，唯一的标准是 PEP 314，它定义了requires, provides and obsoletes参数到distutils.core.setup功能。用于这些参数的元素是 Python 模块名称，例如provides=['xml', 'xml.utils']。 PEP 对标准库依赖关系不是很清楚（我是否必须依赖于 Python >= 2.5 或者我是否必须要求'xml'？）事实证明，没有任何工具可以利用这些字段（甚至 distutils 本身也没有）。
然后是安装工具。它引入了其他类型的依赖关系，这些依赖关系使用project名称而不是modules，例如你可以有setup(..., install_requires=['PyXML', 'Pylons'], tests_require=['nose'])，这非常有用：人们使用唯一的项目名称在 PyPI 上发布软件，您可以在安装脚本中使用这些相同的名称来依赖它们，并且使用 easy_install 或 pip 您可以安装这些依赖项、模块、脚本等。
几年前，当 distutils 再次被接管时，社区标准化了 setuptools 的一些依赖关系想法，生成了 PEP 345，现在已在 distutils2 中实现，旨在取代 distutils 和 setuptools。
总结一下：
- 你的安装脚本中可能有 distutils 风格的模块级依赖项，这是无用的
- 您可能有 setuptools 风格的项目级 deps，它们由基于 setuptools 的工具使用
- 您可以在以下环境中拥有符合 PEP 345 的项目级部门：setup.cfg文件，由 distutils2 使用
因此，为了让我们回答您的问题，您需要告诉我们您拥有哪种类型。对于所有实际问题，不应使用 distutils 风格的模块 deps，因此它留下了 setuptools 项目 deps 或新的 PEP 345 风格的 deps，这些仍然是新的并且尚未广泛使用。 distutils2 有一个用于 setuptools 的兼容层，因此可以使用它从基于 setuptools 的程序中获取您想要的信息setup.py script.
与打包工具无关，还有一个工具可以扫描您的代码以查找您正在使用的模块：它是标准库中的 modulefinder 模块，从其代码的悲伤状态来看，该模块并不是很为人所知或使用。该工具不会告诉您所使用的模块是来自 stdlib 还是第三方项目，也不会告诉您要在您的项目中使用的项目名称。setup.py or setup.cfg file.
HTH
