仓库结构与目录结构¶

pip 的代码库 (GitHub 仓库) 结构为标准的 Python 包。

根目录和工具¶

README、许可证、pyproject.toml 等位于顶层。

AUTHORS.txt
LICENSE.txt
MANIFEST.in
NEWS.rst
pyproject.toml
README.rst
noxfile.py -- pip 使用 Nox，一个由此文件配置的自动化工具。noxfile.py 描述了 pip 在开发过程中使用的几个环境，以简化测试运行方式（这种情况很复杂）。例如：nox -s lint、nox -s test-3.10。我们可以通过将“3.10”更改为“3.7”或类似的方式来运行不同 Python 版本的测试。
.gitattributes
.gitignore
.mailmap
docs/ [文档，使用 Sphinx 构建]
- html/ [可在线获取的 HTML 文档源代码]
- man/ 包含发行版可以通过运行 man pip 来使用的 man 手册
- pip_sphinxext.py [扩展 -- pip 特定的 Sphinx 插件，不适用于其他软件包]
- requirements.txt
news/ [pip 存储新闻片段……每次 pip 进行用户可见的更改时，都会向此目录添加一个文件（通常是一个简短的注释，引用 GitHub 问题），并使用正确的扩展名和名称，以便它包含在变更日志中……因此，每次发布时，维护人员都会删除此目录中的旧文件吗？是的 - 我们使用 towncrier 自动化来生成 NEWS 文件，并自动删除旧内容。有关这方面的更多信息，请参阅贡献者文档！]
- template.rst [变更日志模板 -- 这是 towncrier 使用的文件……这是 jinja 吗？我不知道，请查看 towncrier 文档]
src/ [源代码；见下文]
tools/ [杂项开发工作流程工具，例如需求文件和 CI 文件和帮助程序。例如，自动发布。]
tests/ -- 包含您可以运行的测试。在入门中有说明。
- __init__.py
- conftest.py
- data/ [用于运行测试的测试数据 -- 其中包含伪软件包索引！许多无效或有效的软件包。测试夹具。由功能测试使用]
- functional/ [pip CLI 的功能测试 -- 端到端，在子进程中调用 pip 并根据预期结果检查执行结果。这也是测试套件缓慢的原因]
- lib/ [测试帮助程序]
- unit/ [单元测试 -- 快速、小巧、很棒！]
.github

src 目录¶

在根目录中，src/ 目录包含 pip 的核心源代码。在 src/pip/ 中，_internal/ 包含由 pip 维护人员编写的 pip 代码，而 _vendor/ 是 pip 的依赖项（来自其他软件包的代码）。

在 src/ 中

pip/
- __init__.py
- __main__.py
- _internal/ [所有由 pip 维护人员编写的 pip 代码所在的位置 -- 下划线表示私有。pip 不是一个库 -- 它是一个命令行工具！一个非常重要的区别！想要使用 pip 安装内容的人不应使用内部代码 -- 他们应该使用 CLI。文档中有一条关于此的说明。]
  - __init__.py
  - build_env.py
  - cache.py [包含所有有关如何在 pip 中处理缓存的信息 -- 缓存处理内容。使用来自 PyPI 的 cachecontrol，并由 pip 供应商提供]
  - cli/ [包含用于管理命令行接口的帮助程序和附加代码的子包。使用来自 stdlib 的 argparse]
  - commands/ [从字面上讲 - 每个文件都是 pip CLI 上的命令名称。每个文件都有一个类，定义了设置它所需的条件以及发生的事情]
  - configuration.py
  - download.py
  - exceptions.py
  - index/
  - locations/
  - main.py [旧版入口点]
  - models/ [进程内重构！目标：改进 pip 如何在内部建模它对数据的表示 -- 数据表示。总体清理。数据表示散布在整个代码库中……链接在一个文件的类中定义，然后另一个文件从该文件中导入链接。有时会出现循环依赖关系?!?! 为了防止将来出现这种情况，等等，Pradyun 开始将这些内容移动到 models 目录中。]
  - operations/ -- 有点奇怪的目录…… Freeze.py 曾经在里面。Freeze 是一个操作 -- 曾经有一个 operations.freeze。然后添加了“prepare”（准备 pkg 的操作）。然后添加了“check”用于检查环境状态。] [命令和操作有什么区别？命令是在 CLI 上的；操作将是实际执行命令所述操作的子集的内部代码。例如，install 命令使用 check 和 prepare 的一部分。从长远来看，Pradyun 的目标是：prepare.py 会消失（重构到其他文件中），这样 operations 就只剩下 check 和 freeze………… Pradyun 计划重构它。[这与 utils 相比如何？]
    - install/ -- 用于与安装各种类型项目的模块相关
      - wheel.py 是一个管理安装 wheel 文件的文件。这处理解压缩 wheel -- “解压缩和扩展”。PyPI 上有一个名为 wheel 的软件包用于构建 wheel -- 不要将其与这个混淆。
  - pep425tags.py -- 正在重构到 packaging.tags（PyPI 上的一个库），它位于 pip 的外部（但由 pip 供应商提供）。PEP 425 标签：事实证明，很多人都想要这个！用于构建发行版的兼容性标签 -> 例如，平台、Python 版本等。
  - pyproject.py -- pyproject.toml 是一个新的标准（PEP 518 和 PEP 517）。此文件读取 pyproject.toml 并将这些信息传递给其他地方。其余处理过程发生在另一个文件中。517 和 518 的所有处理都在另一个文件中。
  - req/ [需要大量重构的目录。……还记得步骤 3 吗？依赖关系解析等等？这就是这一步！每个文件都代表……拥有安装和卸载的完整流程，获取有关包的信息……这里有些文件超过 1000 行！（以前更长？！）重构将极大地改善开发人员体验。此外，我们正在 `改进 pip 依赖关系解析器`_ 在 2020 年，因此很多内容都在改变。]