# Hatch vs PDM: gerenciadores de projeto Python comparados

> Hatch vs PDM comparados em ambientes, lockfiles, build backends e padrões PEP. Qual gerenciador de projeto Python se encaixa no seu workflow e na sua CI.

Source: https://latchkey.dev/pt/learn/tool-comparisons/hatch-vs-pdm  
Updated: 2026-06-30

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.

## Comparison

|  | 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.

```Terminal
# 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"
```

> Measure the cold path. Warm local benchmarks favour whichever tool you already have cached, which is exactly the condition a CI runner never has.

## 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.

## FAQ

### Hatch vs PDM: Python Project Managers Compared?

Hatch (from the PyPA) and PDM are both modern, standards-based Python project managers that replace the older setup.py plus virtualenv plus pip flow. They overlap a lot but emphasize different things: Hatch centers on reproducible environments and its hatchling build backend, while PDM centers on a fast dependency resolver and a

### Where each genuinely wins?

PDM wins when you want a committed cross-platform lockfile and a quick resolver without bolting on extra tools; its pdm.lock and pdm install flow are reproducible out of the box. Hatch wins when you publish packages and want a clean, widely adopted build backend (hatchling) plus a matrix of test environments managed by one CLI.

### In CI?

PDM is convenient in CI because pdm install restores an exact, locked environment from pdm.lock. With Hatch, lock reproducibility usually comes from pinning in pyproject.toml or pairing it with pip-tools/uv; its strength in CI is running the same hatch run test matrix locally and on the runner.

### Honest caveats?

Neither is universally "better". Hatch deliberately leaves locking somewhat external, which some teams dislike. PDM bundles more (lock, scripts, plugins) but that means more PDM-specific concepts to learn. The fast-moving uv tool overlaps with both, so evaluate it before committing.

### Which should I choose?

For library authors who want a standard build backend and an env matrix, Hatch fits well. For application teams who want a built-in lockfile and a fast resolver in one tool, PDM is the more complete default.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt