Consider replacing Hatch with uv for project and dependency management

Inizia dal pyproject.toml del progetto e dai comandi Hatch elencati per la compilazione, gli ambienti, gli script, il versionamento, il linting e i test. Confronta queste responsabilità con uv, incluso il uv.lock proposto, e analizza function-template-python per la sua configurazione ereditata. Il lavoro è completo quando vengono documentati i vantaggi e gli svantaggi e viene presa una decisione sull’eventuale sostituzione di Hatch in entrambi i progetti.

What problem are you facing?

When I created this SDK in November 2023, the Python build and project management space was crowded. There was Hatch, Poetry, PDM, Flit, setuptools, and probably others I'm forgetting. There wasn't a clear winner. I picked Hatch because it was a PyPA project, it had a clean pyproject.toml-based configuration, and it covered everything I needed: environments, scripts, building, versioning, and linting (via its Ruff integration).

Today we use Hatch for:

• Building wheels and sdists (hatch build), using hatchling as the PEP 517 build backend.
• Environments with isolated dependencies — a generate env for protoc, a docs env for pdoc, and a hatch-static-analysis env for Ruff.
• Scripts like hatch run generate:protoc and hatch run docs:generate.
• Version management — reading the version from __version__.py at build time.
• Linting via hatch fmt, which wraps Ruff.
• Testing via hatch test, which wraps pytest.

function-template-python uses the same setup, and any new functions built from it will inherit it.

Hatch works. I don't have a concrete problem with it.

What I do have is a growing sense that the ecosystem has converged on uv in the ~18 months since I made this choice. uv didn't exist when I picked Hatch — its first release was February 2024, three months after this SDK. Since then it's grown to 82k GitHub stars (vs Hatch's 7.2k and Poetry's 34.3k) and 14,600 dependent repositories (vs Hatch's 1,800). It has a full-time team at Astral and ships releases at a pace that's hard to ignore.

We already use Astral's Ruff for linting and formatting, and I'm interested in their ty type checker too. Adopting uv would mean our Python build toolchain is entirely Astral: uv for project management, Ruff for linting, and potentially ty for type checking. That's less build plumbing for contributors to learn and install.

uv would also give us a lockfile (uv.lock) for pinning transitive dependencies, which Hatch doesn't support. We pin direct dependencies today but have no control over what versions of their transitive dependencies get installed.

How could this Function help solve your problem?

I think we should evaluate replacing Hatch with uv for project and dependency management in this SDK and in function-template-python. I'll follow up with a comment breaking down what we'd gain and what we'd lose.