儲存庫結構與目錄結構¶

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 來使用這些頁面。
- 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/ [包含輔助程式和用於管理命令列介面的額外程式碼的子套件。使用來自標準程式庫的 argparse]
  - commands/ [確切來說，每個檔案是 pip CLI 上命令的名稱。每個檔案都有定義設定和相關活動內容的類別]
  - configuration.py
  - download.py
  - exceptions.py
  - index/
  - locations/
  - main.py [傳統進入點]
  - models/ [正在進行中的處理refactoring！目標：改善 pip 在內部如何建模其對資料的表示 - 資料表示。整體進行一般清理。資料代表廣泛分散在代碼庫中…。鏈結在一個檔案中定義在一個類別中，然後另一個檔案會從該檔案導入 Link。有時候有循環相依性?!?! 為了防止此類情況在未來發生等問題，Pradyun 開始將這些移至一個 models 資料夾。]
  - operations/ -- 有點奇怪的資料夾…。Freeze.py 過去在其中。Freeze 是一種操作 -- 先前有 operations.freeze。然後新加入「準備」(「準備」一個套件的操作)。然後新加入「檢查」來檢查環境的狀態。] [命令對上操作是什麼？命令在 CLI 上；操作會是一個實際執行命令所述操作的某個子集的內部程式碼片段。install 命令使用 check 和 prepare 的片段，例如。從長遠來看，Pradyun 的目標：prepare.py 消失（重構到其他檔案），這樣 operations 就只是 check 和 freeze…。… Pradyun 計畫重構這個。[與 utils 有何比較？]
    - install/ -- 給與安裝各種專案相關的模組
      - wheel.py 是管理輪檔安裝的檔案。這會處理輪檔的解壓縮 --「解壓縮和展開」。在 PyPI 上有一個套件叫 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 嗎？相依性解決等？這就是該步驟！每個檔案都代表……擁有安裝與解除安裝、取得有關套件的資訊的整個流程。此處的某些檔案長度超過 1,000 行！(以前更長嗎？) 重構將大幅改善開發人員體驗。此外，我們在 2020 年 `改善 pip 相依性解決器`_，因此許多部分都在改變。]
  - utils/ [與 pip…… 雜項功能與檔案被傾倒在這裡（不論是「操作上」的是否）。此處有一些組織。此處有一個需要重構的 models.py。Deprecation.py 和其他項目很有用，但有些項目不屬於此處。應針對重構此處的某些項目建立一些 GitHub 議題。可能包含核取方塊清單的幾個議題。]
  - vcs/ [代表版本控制系統。pip 處理所有版本控制工作——您可以使用的 ``pip install`` 參數之一是版本控制連結。這些指令中有任何一個是已回溯的嗎？沒有，透過子程序。考量到效能，我們（認為）執行此操作（而非 pygitlib2 或類似資源）有其意義，而且必須是純 Python，無法包含 C 函式庫，因為您無法為執行的平台包含已編譯的 C 內容。]
- _vendor/ [來自其他套件的程式碼——pip 的相依性….將它們放在自己的原始程式碼樹中，因為 pip 無法依賴已安裝在機器上的 pip！]