docs: add Package Management category intro

Package Management had no intro, so its meta description fell back to generic text and readers got no guidance on which tool to pick.

Co-Authored-By: Claude <noreply@anthropic.com>

website/data/category_intros/package-management.md

@@ -0,0 +1,33 @@
+Whatever you need from PyPI, uv installs and locks it, and uv-build packages pure Python. Conda is more than a Python package manager: it handles any language.
+
+How to choose:
+
+- A project's dependencies, lockfile, and Python versions: uv
+- Packaging a pure-Python project: uv-build
+- Non-Python dependencies, like C libraries or R: conda
+- Nothing beyond what ships with Python: pip
+- A project already on Poetry: Poetry
+- Tests across several Python versions: Hatch
+- Command-line apps, each in its own environment: pipx
+- C or C++ extension modules: setuptools
+- Build hooks or a flexible project layout: Hatchling
+
+uv is one tool for [your project's dependencies, lockfile, and Python versions](https://docs.astral.sh/uv/), and it covers what you'd otherwise use pip, pipx, and Poetry for. Start with `uv init`, add dependencies with `uv add`, and run your code with `uv run`, which [syncs the environment with the lockfile](https://docs.astral.sh/uv/guides/projects/#running-commands) first. Its `uv pip` commands are meant [for projects not ready to move away from pip](https://docs.astral.sh/uv/pip/).
+
+uv-build is uv's own build backend, which its docs call [a great choice for most Python projects](https://docs.astral.sh/uv/concepts/build-backend/#choosing-a-build-backend). It's for pure-Python code, aims to need no configuration, and by default expects your package in `src/<package_name>/`.
+
+conda manages [packages in any language](https://packaging.python.org/en/latest/key_projects/#conda), Python included, so it fits projects that need compiled non-Python libraries next to their Python ones. Install it with [Miniforge](https://docs.conda.io/projects/conda/en/stable/), which uses the free conda-forge channel. Miniconda and the Anaconda Distribution use Anaconda's repository instead, which [may require a commercial license](https://docs.conda.io/projects/conda/en/stable/user-guide/getting-started.html#before-you-start). In a conda environment, [install as much as you can with conda](https://docs.conda.io/projects/conda/en/stable/user-guide/tasks/manage-environments.html#using-pip-in-an-environment) before you use pip for the rest. To change the environment later, create a new one rather than running conda after pip.
+
+pip is the [standard tool to install packages from PyPI](https://packaging.python.org/en/latest/guides/tool-recommendations/#installing-packages), and it ships with most Python installations. Run it as `python -m pip`, so [it installs into the interpreter you name](https://pip.pypa.io/en/stable/user_guide/#running-pip), and use it inside a [virtual environment](https://pip.pypa.io/en/stable/getting-started/#next-steps). To repeat an install, [pin every version](https://pip.pypa.io/en/stable/topics/repeatable-installs/#pinning-the-package-versions) in a requirements file generated by `pip freeze`. By default, pip doesn't check downloads for tampering, so for deployments its docs [recommend hash-checking mode](https://pip.pypa.io/en/stable/topics/secure-installs/).
+
+Poetry [manages dependencies and packaging](https://python-poetry.org/docs/), with a lockfile for repeatable installs. [Install it in its own virtual environment](https://python-poetry.org/docs/#installation), with pipx for example, and never in the project it manages.
+
+Hatch is a [Python project manager](https://hatch.pypa.io/latest/) for environments, builds, and publishing. You never create its environments by hand: the first command you run in one [creates it](https://hatch.pypa.io/latest/environment/). Define a [matrix](https://hatch.pypa.io/latest/config/environment/advanced/#matrix) to run the same tests across Python versions. For most projects, `hatch test` [runs pytest and coverage.py](https://hatch.pypa.io/latest/tutorials/testing/overview/) with no test environment of your own.
+
+pipx installs command-line apps [each in its own virtual environment](https://pipx.pypa.io/stable/#pip-vs-pipx) and puts their commands on your PATH, and `pipx run` runs an app without installing it. If you already use uv, its tool command does the same job. pipx's docs suggest pipx [when you need its extras](https://pipx.pypa.io/stable/explanation/comparisons.html#picking-one), like installing an app system-wide.
+
+setuptools [builds C and C++ extension modules](https://setuptools.pypa.io/en/latest/userguide/ext_modules.html), and Hatch's docs [recommend it](https://hatch.pypa.io/latest/why/#build-backend) when you need them. Keep your config in `pyproject.toml` and [only the dynamic parts](https://setuptools.pypa.io/en/latest/userguide/quickstart.html#setuppy-discouraged) in `setup.py`. Build with `python -m build` [instead of running `setup.py`](https://packaging.python.org/en/latest/discussions/setup-py-deprecated/).
+
+Hatchling is the build backend the Python Packaging User Guide's [tutorial uses by default](https://packaging.python.org/en/latest/tutorials/packaging-projects/#choosing-a-build-backend). It supports plugins and [build hooks](https://hatch.pypa.io/latest/config/build/#build-hooks), and uv's docs point to it when you need build scripts or a more flexible project layout.
+
+Whichever tool builds your package, declare the backend in `pyproject.toml`'s `[build-system]` table and your metadata in [the standard `[project]` table](https://packaging.python.org/en/latest/guides/writing-pyproject-toml/), which most build backends understand. For an app, commit [uv.lock](https://docs.astral.sh/uv/guides/projects/#uvlock) or [poetry.lock](https://python-poetry.org/docs/basic-usage/#as-an-application-developer), so every machine installs the same versions. A library's lockfile doesn't reach the apps that install it, since they [resolve its dependencies themselves](https://python-poetry.org/docs/basic-usage/#as-a-library-developer).