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