Hatch vs PDM: gerenciadores de projeto Python comparados
Escolha o PDM se você quer um resolver rápido com um lockfile embutido e instalações locais no estilo PEP 582; escolha o Hatch se você quer um build backend padronizado, uma matriz de ambientes e scripting de projeto a partir de uma única ferramenta.
Hatch (da PyPA) e PDM são gerenciadores de projeto Python modernos e baseados em padrões que substituem o fluxo mais antigo de setup.py mais virtualenv mais pip. Eles se sobrepõem bastante, mas enfatizam coisas diferentes: o Hatch se concentra em ambientes reproduzíveis e em seu build backend hatchling, enquanto o PDM se concentra em um resolver de dependências rápido e em um lockfile comitado (pdm.lock). Ambos leem pyproject.toml.
| Hatch | PDM | |
|---|---|---|
| Configuração | pyproject.toml ([tool.hatch]) | pyproject.toml ([tool.pdm]) |
| Lockfile | Sem lock embutido (usa hatch-pip-compile ou externo) | pdm.lock embutido |
| Build backend | hatchling (backend standalone popular) | pdm-backend |
| Ambientes | Ambientes nomeados e uma matriz de testes | Venv único do projeto (.venv no projeto) |
| Scripts/tarefas | hatch run + scripts | pdm run + scripts |
| Padrões | PEP 517/518/621 | PEP 517/518/621, histórico de PEP 582 |
Onde cada um genuinamente vence
O PDM vence quando você quer um lockfile comitado e multiplataforma e um resolver rápido sem adicionar ferramentas extras; seu fluxo pdm.lock e pdm install é reproduzível de fábrica. O Hatch vence quando você publica pacotes e quer um build backend limpo e amplamente adotado (hatchling) mais uma matriz de ambientes de teste gerenciada por uma única CLI. Muitos projetos usam o hatchling como build backend mesmo quando seu workflow do dia a dia é pip ou uv.
Na CI
O PDM é conveniente na CI porque pdm install restaura um ambiente exato e travado a partir do pdm.lock. Com o Hatch, a reprodutibilidade do lock normalmente vem de fixar versões no pyproject.toml ou de combiná-lo com pip-tools/uv; sua força na CI é executar a mesma matriz hatch run test localmente e no runner.
Ressalvas honestas
Nenhum dos dois é universalmente "melhor". O Hatch deliberadamente deixa o travamento um tanto externo, o que algumas equipes não gostam. O PDM agrega mais (lock, scripts, plugins), mas isso significa mais conceitos específicos do PDM para aprender. A ferramenta uv, em rápida evolução, se sobrepõe a ambos, então avalie-a antes de se comprometer.
Decide with your own numbers, not a feature table
Feature comparisons age badly and rarely decide anything, because both tools in a mature category can do the job. What differs is how each behaves on your repository, and that takes one afternoon to measure.
# time a cold install with each candidate, cache cleared
hyperfine --prepare "rm -rf node_modules" --warmup 1 \
"<tool-a> install" "<tool-b> install"
# and the thing CI actually pays for: a cold run with no local cache
docker run --rm -v "$(pwd):/w" -w /w node:22 sh -c "<tool> install"What actually changes when you switch
- Lockfile format. A switch is a one-way door for anyone still on the old tool until everyone migrates, so plan it as a single coordinated change.
- Resolution strictness. Tools differ on whether an undeclared transitive import works, and the stricter one will surface latent bugs as new failures.
- CI cache configuration. The cache path and key differ per tool; carrying over the old ones silently disables caching.
- Everyone on the team and every runner must move together. Pin the version so they cannot drift.
O veredito
Para autores de bibliotecas que querem um build backend padrão e uma matriz de ambientes, o Hatch se encaixa bem. Para equipes de aplicações que querem um lockfile embutido e um resolver rápido em uma única ferramenta, o PDM é o padrão mais completo.