Consider replacing Hatch with uv for project and dependency management

Bắt đầu với pyproject.toml của dự án và các lệnh Hatch được liệt kê để build, môi trường, script, quản lý phiên bản, linting và kiểm thử. So sánh các trách nhiệm đó với uv, bao gồm uv.lock được đề xuất, và xem xét function-template-python để đánh giá thiết lập được kế thừa. Công việc được xem là hoàn tất khi đã ghi lại những gì sẽ đạt được và mất đi, đồng thời đưa ra quyết định về việc có thay thế Hatch trong cả hai dự án hay không.

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.