摘要

本 PEP 提议将 `pkg_resources` 模块的增强版本添加到标准库中。

`pkg_resources` 是一个用于查找和管理 Python 包/版本依赖项以及访问捆绑文件和资源（包括 ZIP 文件内的资源）的模块，例如 ZIP 格式的 `.egg` 文件。目前，`pkg_resources` 只能通过安装整个 `setuptools` 发行版来获得，但它不依赖于 setuptools 的任何其他部分；实际上，它构成了 Python Eggs 的全部运行时支持库，并且独立可用。

此外，通过一项功能添加，该模块还可以支持轻松引导安装多个 Python 包管理工具，包括 `setuptools`、`workingenv` 和 `zc.buildout`。

提案

本 PEP 并不提议将 `setuptools` 包含在标准库中，而是提议仅将 `pkg_resources` 添加到 Python 2.6 和 3.0 的标准库中。`pkg_resources` 比 setuptools 的其余部分稳定得多，在过去 12 个月里几乎没有新增功能。

然而，本 PEP 还提议在将一个新功能添加到 stdlib 之前，先将其添加到 `pkg_resources` 中。具体来说，应该可以实现类似如下的操作：

python -m pkg_resources SomePackage==1.2

来请求从 PyPI 下载和安装 `SomePackage`。此功能不会取代 `easy_install`；相反，它将依赖于 `SomePackage` 通过 PyPI XML-RPC API 列出供下载的纯 Python `.egg` 文件，并且这些 egg 将被放置在 `$PYTHON_EGG_CACHE` 目录中，默认情况下不可导入。（并且不会安装任何脚本。）但是，如果下载的 egg 包含安装引导代码，它将有机会运行。

这些限制将允许代码非常简单，同时仍然足够强大，能够支持用户仅通过在命令行中提供包名来下载像 `setuptools`、`workingenv` 和 `zc.buildout` 这样的包管理工具。

基本原理

许多用户曾要求将 `setuptools` 包含在标准库中，以避免用户需要经历繁琐的引导过程。然而，大多数引导的复杂性来自于这样一个事实：setuptools 安装的代码除非已经安装了 setuptools，否则无法使用 `pkg_resources` 运行时模块。因此，安装 setuptools 在某种意义上需要 setuptools 已经安装。

其他 Python 包管理工具，如 `workingenv` 和 `zc.buildout`，也面临类似的引导问题，因为它们都使用 setuptools，但同时也希望为用户提供接近“一步安装”的体验。如果 `pkg_resources` 已经存在，并且能够从 PyPI 下载预打包的 egg，那么为这些工具以及未来出现的任何其他此类工具创建引导实用程序的复杂性将大大降低。

（这也意味着，如果仅仅使用 egg 而不是构建它们，就不需要安装 setuptools。）

最后，除了提供访问通过 setuptools 或其他打包工具构建的 egg 的方法外，还应该指出，从 Python 2.5 开始，distutils 安装的包元数据（又名 `PKG-INFO`）文件可以被 `pkg_resources` 读取，以识别 `sys.path` 中已安装了哪些分发包。在通过系统包工具（如 RPM）安装 Python 包的环境中，`pkg_resources` 模块提供了一个 API，用于检测已安装了哪些包的哪些版本，即使这些包是使用 distutils 而不是 setuptools 安装的。

实现与文档

`pkg_resources` 实现维护在 Python SVN 存储库的 `/sandbox/trunk/setuptools/` 下；请参阅 `pkg_resources.py` 和 `pkg_resources.txt`。有关 `pkg_resources` 支持的 egg 格式的文档可以在 `doc/formats.txt` 中找到。这些文档的 HTML 版本可在以下网址找到：

• http://peak.telecommunity.com/DevCenter/PkgResources 和
• http://peak.telecommunity.com/DevCenter/EggFormats

（这些 HTML 版本适用于 setuptools 0.6；它们可能无法反映 Subversion 主干的 `.txt` 版本中的所有更改。）

版权

本文档已置于公共领域。