Revert "docs: fix broken pip links"

This reverts commit 4b8bf14.

Author: 56kyle

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-documentation:`pip` + :python:venv-tutorial:`venv` / :virtualenv-documentation:`virtualenv` (+ :pip-tools-documentation:`pip-tools`)
+### Option 1: [pip](pip-documentation) + :python:venv-tutorial:`venv` / :virtualenv-documentation:`virtualenv` (+ :pip-tools-documentation:`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-documentation:`pip` understands PEP 621 for installing from `pyproject.toml`. :pip-tools-documentation:`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-documentation:`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-documentation:`pip-tools` is pure Python and cross-platform.
-  - **Performance:** Moderate. :pip-documentation:`pip`'s dependency resolver can be slow for large/complex graphs. `pip-compile` adds time. :python:venv-tutorial:`venv`/:virtualenv-documentation:`virtualenv` 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:`venv`/:virtualenv-documentation:`virtualenv` 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 :python:venv-tutorial:`venv`s, `pip install`, and `requirements.txt`. Highest compatibility score.
@@ -95,7 +95,7 @@ We evaluated the most prominent options for managing Python project dependencies
   - **Performance:** Excellent. **Significantly faster** than all Python-based dependency managers and installers for resolution and installation. This is a major differentiating factor and aligns strongly with automating quickly.
   - **Developer Experience (DX):** Excellent. Provides intuitive integrated CLI commands (`uv add`, `uv remove`, `uv update`, `uv run`, `uv build`, `uv publish`, `uv venv`). Comparable DX to PDM/Poetry for standard tasks.
   - **Dependency Group Management:** Excellent. Supports standard `[project.optional-dependencies]` for defining groups and managing them via CLI.
-  - **Integration:** High (Growing Rapidly). Explicitly designed to replace/interoperate with standards (:python:venv-tutorial:`venv`, :pip-documentation:`pip`), works well with standard build processes. Integrations are rapidly being built due to its popularity.
+  - **Integration:** High (Growing Rapidly). Explicitly designed to replace/interoperate with standards (:python:venv-tutorial:`venv`, [pip](pip-documentation)), works well with standard build processes. Integrations are rapidly being built due to its popularity.
   - **Maturity & Stability:** Moderate (Rapidly Developing). V0.x, fast-moving development. While technically robust and backed by solid engineering, it's not as historically battle-tested across _all_ complex edge cases as 1.0+ tools. Carries some risk of minor behavioral changes or discovering new edge cases in v0.x.
   - **Community & Documentation:** High (Exploding). Very active development, rapidly growing user base, excellent and quickly improving documentation.
 - **Conclusion:** Delivers outstanding performance and a strong modern DX, now with PEP 621 editing capabilities. Its primary practical trade-off compared to more mature tools is its v0.x status, which implies a faster pace of change and less historical battle-testing across edge cases. However, its technical merits strongly align with the template's philosophy prioritizing speed and thoughtful design.
@@ -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-documentation:`PDM`/:poetry-documentation:`Poetry`/:pip-documentation:`pip`+:python:venv-tutorial:`venv`.
+  - **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-documentation:`PDM`/:poetry-documentation:`Poetry`/[pip](pip-documentation)+:python:venv-tutorial:`venv`.
   - **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-documentation:`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-documentation:`pip` and :twine-documentation:`twine`?
+- **Standard Artifacts:** Does it produce standard `.sdist` and `.whl` files consumable by tools like [pip](pip-documentation) and :twine-documentation:`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).