Revert "docs: replace non existent pip intersphinx usage with extlink"

This reverts commit 3fbc5f1.

Author: 56kyle

docs/conf.py

@@ -113,6 +113,7 @@
 
 intersphinx_mapping = {
     "python": ("https://docs.python.org/3", None),
+    "pip": ("https://pip.pypa.io/en/stable/", None),
 }
 
 html_theme = "furo"

docs/topics/02_dependency-management.md

@@ -26,14 +26,14 @@ This section evaluates different tools and approaches for managing project depen
 
 We evaluated the most prominent options for managing Python project dependencies:
 
-### Option 1: :pip:`pip` + :python:venv-tutorial) / [:term:`virtualenv`](virtualenv:`venv` (+ :pip-tools:`pip-tools`)
+### Option 1: [pip](pip-documentation) + :python:venv-tutorial) / [:term:`virtualenv`](virtualenv:`venv` (+ :pip-tools:`pip-tools`)
 
 - **Description:** The traditional standard using `pip` for installation within isolated virtual environments created by `venv` (stdlib) or `virtualenv`. `pip-tools` (`pip-compile`, `pip-sync`) is often added to manage dependencies via `requirements.in` and generate reproducible `requirements.txt` lock files.
 - **Evaluation:**
-  - **PEP Compliance:** Moderate. :pip:`pip` understands PEP 621 for installing from `pyproject.toml`. :pip-tools:`pip-tools` can read from `pyproject.toml`. No native support for standard lock file formats (PEP 665), relies on generated `requirements.txt` which is a common convention but lacks richer metadata.
+  - **PEP Compliance:** Moderate. [pip](pip-documentation) understands PEP 621 for installing from `pyproject.toml`. :pip-tools:`pip-tools` can read from `pyproject.toml`. No native support for standard lock file formats (PEP 665), relies on generated `requirements.txt` which is a common convention but lacks richer metadata.
   - **Reproducibility:** High _with `pip-tools`_. `requirements.txt` generated by `pip-tools` provides strong pinning. Pure `pip` relies on `pip freeze` which is less deterministic.
   - **OS Interoperability:** Excellent. Core tools are foundational Python utilities robust across OSs. :pip-tools:`pip-tools` is pure Python and cross-platform.
-  - **Performance:** Moderate. :pip:`pip`'s dependency resolver can be slow for large/complex graphs. `pip-compile` adds time. :python:venv-tutorial)/[:term:`virtualenv`](virtualenv:`venv` creation/activation faster than some, slower than others (like uv).
+  - **Performance:** Moderate. [pip](pip-documentation)'s dependency resolver can be slow for large/complex graphs. `pip-compile` adds time. :python:venv-tutorial)/[:term:`virtualenv`](virtualenv:`venv` creation/activation faster than some, slower than others (like uv).
   - **Developer Experience (DX):** Moderate. Requires multi-step workflow: create env, activate, manually edit requirement files, run `pip-compile`, run `pip-sync`/`pip install -r`. No single command for `add` or `remove`.
   - **Dependency Group Management:** Achieved by manually managing multiple `.in` / `.txt` files or leveraging `[project.optional-dependencies]` via `pip-tools`, less integrated than other tools.
   - **Integration:** Excellent. As the standard, most ecosystem tools inherently understand [:term:`venv`](python:venv-tutorial)s, `pip install`, and `requirements.txt`. Highest compatibility score.
@@ -110,7 +110,7 @@ We evaluated the most prominent options for managing Python project dependencies
   - **Performance:** Excellent. Inherits `uv`'s speed for core dependency operations.
   - **Developer Experience (DX):** Very High. Provides a very clean, unified CLI (`rye init`, `rye add`, `rye run`, `rye build`, `rye publish`). Opinionated but can simplify workflow buy-in.
   - **Dependency Group Management:** Excellent. Supports standard `[project.optional-dependencies]`.
-  - **Integration:** Moderate (Growing). As an all-in-one, tools need to interact with `rye run` or be compatible with its env structure. Less explicit support yet than for :pdm:`PDM`/:poetry:`Poetry`/:pip:`pip`+[:term:`venv`](python:venv-tutorial).
+  - **Integration:** Moderate (Growing). As an all-in-one, tools need to interact with `rye run` or be compatible with its env structure. Less explicit support yet than for :pdm:`PDM`/:poetry:`Poetry`/[pip](pip-documentation)+[:term:`venv`](python:venv-tutorial).
   - **Maturity & Stability:** Low (Experimental). **Explicitly labeled experimental**. Subject to breaking changes and design evolution. This is the most significant factor for a foundation template.
   - **Community & Documentation:** High (Active, niche). Very active development due to creator profile. Rapid adoption among early adopters.
 - **Conclusion:** Highly promising unified workflow tool built on :uv:`uv`'s performance. However, its **experimental status** makes it too high-risk for a template aiming to provide a _robust_ foundation based on current, albeit rapidly developing, _stable_ tooling. A tool marked "experimental" should not be the default cornerstone of a widely used template unless the user explicitly opts into that level of risk.

docs/topics/09_packaging-build.md

@@ -14,7 +14,7 @@ This section evaluates the tools and approaches for creating standard Python dis
 ## Evaluation Criteria
 
 - **PEP Compliance (Build System & Metadata):** Strict adherence to PEP 517 (build frontends/backends) and PEP 621 (metadata in pyproject.toml). Adherence to PEP 427 (Wheel specification).
-- **Standard Artifacts:** Does it produce standard `.sdist` and `.whl` files consumable by tools like :pip:`pip` and :twine:`twine`?
+- **Standard Artifacts:** Does it produce standard `.sdist` and `.whl` files consumable by tools like [pip](pip-documentation) and :twine:`twine`?
 - **OS Interoperability (Build Process):** Does the tool and its backend enable building packages reliably across Linux, macOS, and Windows, particularly for projects with native extensions?
 - **Support for Native Extensions:** How well does it support including and compiling code written in other languages (e.g., Rust, C, C++) into the built wheel?
 - **Reproducible Builds:** Does the build process ensure the same inputs reliably produce the same outputs (within acceptable build system variations)? Relies on PEP 518 (build requires isolation).

docs/topics/10_packaging-publish.md

@@ -8,7 +8,7 @@ This section evaluates tools and approaches for uploading Python distribution pa
 - Handle authentication with the package index securely.
 - Integrate seamlessly into automated workflows (Task Automation, CI/CD).
 - Ensure the publishing process is OS-interoperable.
-- Produce packages compatible with installation by standard tools like :pip:`pip`. (Addressed in Area 09's Build Process).
+- Produce packages compatible with installation by standard tools like [:py:mod:`pip`](pip-documentation). (Addressed in Area 09's Build Process).
 
 ## Evaluation Criteria
 

docs/topics/11_container-build.md

@@ -32,7 +32,7 @@ This section evaluates the process and tools for building application container
 
   - **Standardization (Format):** Excellent. `Dockerfile` is the **industry standard** text-based format for defining container images, widely understood and universally compatible across container runtimes.
   - **Best Practice Support:** Excellent. The `Dockerfile` syntax explicitly supports crucial best practices like **multistage builds** (`FROM ... AS <name>`), using the `USER` instruction for non-root users, selecting minimal base images (e.g., `python:3.x-slim`, Alpine, Distroless), managing dependency caching layers effectively via step ordering, copying standard artifacts (like built wheels from Area 09) instead of source. The tool (`docker build`/`podman build`) implements these features.
-  - **Packaging Integration:** Excellent. A standard `Dockerfile` workflow involves **copying the project's built wheel** (Area 09) into the image and installing it with :pip:`pip` or the project's chosen manager ([`uv`](uv-documentation)). Alternatively, it can copy source/lock files and install dependencies with the manager directly _inside_ the build. This directly leverages the output of packaging and dependency management steps.
+  - **Packaging Integration:** Excellent. A standard `Dockerfile` workflow involves **copying the project's built wheel** (Area 09) into the image and installing it with [:py:mod:`pip`](pip-documentation) or the project's chosen manager ([`uv`](uv-documentation)). Alternatively, it can copy source/lock files and install dependencies with the manager directly _inside_ the build. This directly leverages the output of packaging and dependency management steps.
   - **Reproducibility:** High (Process). Given the same `Dockerfile`, build context files, and base image, the `docker build`/`podman build` process is highly reproducible layer-by-layer. Reliability of layer caching aids consistent builds.
   - **OS Interoperability (Tool):** Moderate (Runtime Dependency), Excellent (CLI). The `docker build` or `podman build` command-line tools are **OS-interoperable**. However, they require the :docker:`Docker` or :podman:`Podman` daemon/runtime to be installed and running on the host machine, which is an external dependency.
   - **CLI Usability:** Excellent. Simple command (`docker build . -t <image_name>`) is intuitive and standard.