Why did uv originally use Hatch as a build backend?
Note
uv init declares uv_build, uv’s own build backend, for the projects it creates. Hatchling still works and existing projects using it need no changes.
When uv first launched, it didn’t implement its own build backend for creating Python packages. Instead, it used existing backends when packaging projects.
Running uv init with the --package flag originally set up Hatchling (hatch’s build backend) as the default backend in the generated pyproject.toml:
[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"This was purely a configuration choice: uv needed to select some backend for packaged projects, and Hatchling provided a modern, standards-compliant option with minimal dependencies. Now that uv_build is the default, new projects use uv’s own backend, but the rationale for choosing Hatchling originally still explains why so many existing uv projects use it.
What is the uv build backend (uv_build)? covers what the newer default configures, what it refuses to build, and how to decide whether an existing Hatchling project should move.
Tip
Hatchling’s plugin system is one practical reason to keep it. Tag-driven versioning through the uv-dynamic-versioning plugin works with Hatchling but not uv_build. See How to add dynamic versioning to uv projects.