pip É Lento, Poetry Complexo: UV Chegou Resolvendo o Python

Introdução

Se você já trabalhou com Python por mais de cinco minutos, provavelmente já viveu esse ritual: criar um ambiente virtual com venv, instalar pacotes com pip, descobrir que precisa do pip-tools para gerar um lockfile, usar pyenv para trocar de versão do Python, considerar o Poetry mas desistir da complexidade, e eventualmente aceitar que o gerenciamento de dependências em Python é um exercício de paciência.

O ecossistema Python sempre foi assim — poderoso, mas fragmentado. Cada ferramenta resolve um pedaço do problema. Nenhuma resolve tudo. E o desenvolvedor fica no meio, colando peças como um quebra-cabeça infinito.

Isso mudou. Em fevereiro de 2024, a Astral — a mesma empresa por trás do Ruff, o linter Python mais rápido do mundo — lançou o UV: um gerenciador de pacotes, ambientes virtuais e versões do Python escrito em Rust, até 100 vezes mais rápido que o pip. E ele não veio para ser mais uma peça do quebra-cabeça. Ele veio para ser o quebra-cabeça inteiro.

Neste artigo, vamos explorar:

• A história do Python — quem criou, quando, e quem mantém hoje
• Por que Python ganhou tanta notoriedade nos últimos anos
• O problema de fragmentação que o UV resolve
• O que é o UV, quem criou, e como usá-lo na prática
• E a pergunta que não cala: em aplicações complexas, com padrões arquiteturais e modularidade, Python compete com C#? Se você já usa Python ou está avaliando se deve usá-lo, este artigo é para você.

Python: Uma Breve História

Origens

O Python foi criado por Guido van Rossum, um programador holandês que trabalhava no CWI (Centrum Wiskunde & Informatica) em Amsterdã. O desenvolvimento começou no final de 1989, e a primeira versão pública — Python 0.9.0 — foi lançada em fevereiro de 1991.

O nome não tem nada a ver com cobras. Guido era fã do grupo de comédia britânico Monty Python, e queria um nome curto, misterioso e levemente irreverente. Funcionou.

Filosofia

Desde o início, Python foi projetado com uma filosofia clara: legibilidade acima de tudo. Onde outras linguagens usam chaves {} e ponto-e-vírgula ;, Python usa indentação. A ideia era que o código deveria ser tão fácil de ler quanto de escrever.

Essa filosofia foi formalizada no Zen of Python (PEP 20), que você pode ver rodando import this no interpretador:

import this

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Readability counts.
There should be one -- and preferably only one -- obvious way to do it.

💡 O Zen of Python não é apenas poesia — ele guia decisões de design da linguagem até hoje.

Guido e o BDFL

Por quase três décadas, Guido atuou como BDFL — Benevolent Dictator For Life (Ditador Benevolente Vitalício). Ele tinha a palavra final sobre qualquer decisão de design da linguagem.

Isso mudou em julho de 2018, quando a controversa PEP 572 (que introduziu o operador :=, apelidado de walrus operator) gerou debates tão intensos na comunidade que Guido decidiu se afastar. Ele renunciou ao título de BDFL e se aposentou da liderança direta.

Quem mantém Python hoje

Desde 2019, Python é governado por um Steering Council — um comitê eleito de cinco membros que toma as decisões de design e direção da linguagem. O conselho é eleito pela comunidade de core developers a cada release. Por trás do Steering Council está a Python Software Foundation (PSF), uma organização sem fins lucrativos que cuida da infraestrutura, eventos, financiamento e proteção da marca Python.

ℹ️ Guido van Rossum trabalhou na Dropbox (2013–2019) e depois na Microsoft (2020–2023), onde contribuiu significativamente para a performance do CPython (o interpretador padrão). Hoje segue como core developer emeritus, mas sem poder de veto.

Versões marcantes

⚠️ A migração de Python 2 para Python 3 foi uma das mais dolorosas da história da computação. Levou mais de 12 anos — Python 2 só teve seu EOL (End of Life) em janeiro de 2020. Essa experiência traumática moldou a comunidade: desde então, Python evita quebras de compatibilidade a todo custo.

Por Que Python Ganhou Tanta Notoriedade

Se em 2010 alguém te dissesse que Python seria a linguagem mais popular do mundo em poucos anos, você provavelmente duvidaria. Naquela época, o reinado era de Java, C e C++. Python era visto como linguagem de script, boa para automação e pouco mais. O que mudou?

A revolução dos dados e da IA

A ascensão da ciência de dados, do machine learning e da inteligência artificial colocou Python no centro do mapa. Não porque Python fosse a linguagem mais rápida ou mais robusta — mas porque o ecossistema se formou ao redor dela:

Quando TensorFlow (Google, 2015) e PyTorch (Meta, 2016) escolheram Python como interface principal, o destino estava selado. Pesquisadores, cientistas de dados e engenheiros de ML se concentraram em Python, e o efeito de rede fez o resto.

Adoção acadêmica

Universidades no mundo inteiro passaram a ensinar programação com Python em vez de Java ou C. O MIT trocou seu curso introdutório para Python em 2009. Stanford seguiu. A consequência: uma geração inteira de desenvolvedores cresceu com Python como primeira linguagem.

Versatilidade

Python não é apenas para IA. Ele tem presença relevante em:

• Web: Django (full-stack), FastAPI (APIs modernas), Flask (microframework)
• Automação e DevOps: Ansible, scripts de infraestrutura, CI/CD
• Scripting: substituição de Bash para tarefas complexas
• APIs e microsserviços: com FastAPI + Pydantic
• Educação: pela sintaxe limpa e barreira de entrada baixa

Python em números (2025–2026)

💡 Python não é necessariamente a melhor linguagem para cada problema. Mas é a linguagem com o menor atrito para começar — e isso conta muito quando o objetivo é validar ideias, prototipar ou iterar rapidamente.

O Problema Que UV Resolve

Agora que entendemos por que Python é tão popular, vamos ao ponto que todo desenvolvedor Python conhece bem: o caos do gerenciamento de pacotes e ambientes.

O ecossistema antes do UV

A história do gerenciamento de dependências em Python é uma história de fragmentação. Cada ferramenta resolve um pedaço do problema, mas nenhuma resolve tudo:

O fluxo típico antes do UV

Para montar um projeto Python “direito” antes do UV, o desenvolvedor precisava combinara múltiplas ferramentas:

# ❌ Fluxo fragmentado (antes do UV)

# 1. Instalar a versão certa do Python
pyenv install 3.12.1
pyenv local 3.12.1

# 2. Criar ambiente virtual
python -m venv .venv
source .venv/bin/activate    # Linux/macOS
# .venv\Scripts\Activate.ps1 # Windows

# 3. Instalar dependências
pip install fastapi uvicorn

# 4. Gerar lockfile (se usando pip-tools)
pip install pip-tools
pip-compile requirements.in -o requirements.txt

# 5. Executar ferramentas de linting (se usando pipx)
pipx install ruff
ruff check .

Cinco ferramentas diferentes. Cinco comandos de instalação. Cinco coisas para documentar e explicar para quem chega no projeto. Esse é o problema que o UV resolve.

⚠️ O Poetry tentou unificar parte desse fluxo, e para muitos projetos funciona bem. Mas a resolução de dependências é lenta (escrita em Python), o pyproject.toml tem convenções próprias que divergem dos padrões PEP, e ele ainda exige pyenv separado para gerenciar versões do Python.

UV: O Que É e Quem Criou

A Astral e Charlie Marsh

O UV foi criado pela Astral, uma empresa fundada por Charlie Marsh em 2023. Charlie é um engenheiro de software americano que antes de fundar a Astral trabalhava com infraestrutura Python e percebeu que as ferramentas fundamentais do ecossistema estavam décadas atrás do que outras linguagens ofereciam.

A Astral já era conhecida pelo Ruff — um linter e formatter para Python escrito em Rust que é 100 a 300 vezes mais rápido que ferramentas equivalentes como Flake8 e Black. O sucesso do Ruff provou que reescrever tooling Python em Rust gerava ganhos reais e imensos.

Em fevereiro de 2024, a Astral lançou o UV com a mesma premissa: pegar o que o ecossistema Python fazia de forma lenta e fragmentada e reescrever em Rust, rápido e unificado.

💡 A Astral recebeu investimento de US$ 4 milhões da Accel para desenvolver o UV e o Ruff. Charlie Marsh é ex-engenheiro do Spring Health e do Khan Academy.

O que o UV faz

O UV é um toolkit unificado para Python, escrito em Rust. Ele substitui — sozinho — as seguintes ferramentas:

┌─────────────────────────────────────────────────────────┐
│                         UV                              │
│                                                         │
│   ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  │
│   │ Gerenciador  │  │  Ambientes   │  │  Versões do  │  │
│   │ de pacotes   │  │  virtuais    │  │  Python      │  │
│   │ (pip,        │  │ (virtualenv, │  │ (pyenv)      │  │
│   │  pip-tools)  │  │  venv)       │  │              │  │
│   └──────────────┘  └──────────────┘  └──────────────┘  │
│                                                         │
│   ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  │
│   │ Gerenciador  │  │  Execução    │  │  Lockfile    │  │
│   │ de projetos  │  │  de scripts  │  │  nativo      │  │
│   │ (poetry)     │  │  e tools     │  │  (uv.lock)   │  │
│   │              │  │  (pipx)      │  │              │  │
│   └──────────────┘  └──────────────┘  └──────────────┘  │
│                                                         │
└─────────────────────────────────────────────────────────┘

Em termos concretos:

Velocidade

A diferença de velocidade não é incremental — é de outra ordem de grandeza:

📌 Esses números variam conforme o projeto e o ambiente, mas a ordem de grandeza é consistente. O UV faz em milissegundos o que o pip faz em segundos — e em segundos o que o pip faz em minutos.

Essa velocidade não é acidente. O UV é escrito em Rust, com resolução de dependências implementada em um solver SAT otimizado (PubGrub), cache agressivo, downloads paralelos e zero overhead de interpretador Python.

UV na Prática

Chega de teoria. Vamos ver o UV funcionando.

Instalação

# Windows (PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

# Linux / macOS
curl -LsSf https://astral.sh/uv/install.sh | sh

# Via pip (se preferir — mas perde parte da graça)
pip install uv

# Via Homebrew (macOS)
brew install uv

Após instalar, verifique:

uv --version

uv 0.6.x

Criar um projeto novo

uv init meu-projeto-api
cd meu-projeto-api

O UV gera a seguinte estrutura:

meu-projeto-api/
├── .python-version      # Versão do Python fixada
├── pyproject.toml        # Metadados e dependências do projeto
├── README.md
└── main.py               # Entrypoint básico

O pyproject.toml gerado segue os padrões PEP (621, 517):

[project]
name = "meu-projeto-api"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.12"
dependencies = []

💡 Diferente do Poetry, que usa chaves proprietárias como [tool.poetry], o UV segue os padrões PEP oficiais. Isso significa que seu pyproject.toml é compatível com qualquer ferramenta que siga as PEPs.

Adicionar dependências

# Adicionar dependências de produção
uv add fastapi uvicorn[standard]

# Adicionar dependências de desenvolvimento
uv add --dev pytest ruff mypy

O que acontece por baixo:

• O UV atualiza o pyproject.toml com as novas dependências
• Resolve todas as dependências (em milissegundos)
• Gera/atualiza o uv.lock — um lockfile com hashes e versões exatas
• Cria o ambiente virtual (.venv/) automaticamente, se não existir
• Instala tudo no ambiente virtual Tudo em um único comando. Em menos de dois segundos.

Executar o projeto

# Executar diretamente (UV ativa o venv automaticamente)
uv run uvicorn main:app --reload

# Ou executar qualquer script Python
uv run python main.py

💡 Não precisa ativar o ambiente virtual manualmente. O uv run faz isso por você. Acabou o source .venv/bin/activate.

Gerenciar versões do Python

# Listar versões disponíveis
uv python list

# Instalar uma versão específica
uv python install 3.12

# Fixar a versão do projeto
uv python pin 3.12

O UV baixa e gerencia as versões do Python sem precisar do pyenv. Funciona em Windows, Linux e macOS.

Executar ferramentas sem instalar

# Executar o Ruff sem instalar no projeto
uvx ruff check .

# Executar o Black sem instalar
uvx black --check .

# Executar qualquer ferramenta do PyPI
uvx httpie https://api.github.com

O uvx é equivalente ao npx do Node.js — executa ferramentas Python em ambientes temporários, sem poluir seu projeto.

Fluxo completo com UV

Lembra do fluxo fragmentado com cinco ferramentas? Agora com UV:

# ✅ Fluxo unificado com UV

# 1. Criar projeto (já fixa a versão do Python)
uv init meu-projeto
cd meu-projeto

# 2. Instalar dependências (cria venv + lockfile automaticamente)
uv add fastapi uvicorn[standard]
uv add --dev pytest ruff

# 3. Executar (ativa venv automaticamente)
uv run uvicorn main:app --reload

# 4. Rodar testes
uv run pytest

# 5. Linting (sem instalar no projeto)
uvx ruff check .

Uma ferramenta. Cinco linhas. Zero fricção.

Quando Usar UV

Cenários ideais

O UV é a escolha certa quando você:

• Está começando um projeto novo em Python — o uv init dá a estrutura padrão perfeita
• Quer velocidade no CI/CD — instalar dependências em 1 segundo em vez de 30 faz diferença em pipelines
• Trabalha com múltiplas versões do Python — uv python install substitui pyenv sem fricção
• Quer reprodutibilidade — o uv.lock garante que todos no time usem exatamente as mesmas versões
• Precisa de algo simples — um comando para tudo, sem configuração complexa
• Mantém monorepos Python — o UV suporta workspaces no estilo Cargo/npm
• Quer padronizar o toolchain — uma ferramenta para gerenciar tudo, de venv a lockfile

Cenários onde ainda avaliar

💡 O UV é compatível com o pip. Você pode usar uv pip install -r requirements.txt como substituto direto do pip — mesma interface, velocidade de Rust. Essa é a forma mais segura de experimentar sem mudar nada no projeto.

Python vs C# em Aplicações Complexas

Essa é a pergunta que motivou metade deste artigo: quando a aplicação precisa ser modular, com padrões arquiteturais como Clean Architecture, CQRS, Hexagonal — vale a pena usar Python em vez de C#? Existe ganho real?

A resposta honesta é: depende do que você chama de “ganho”.

Comparativo completo

Python para aplicações arquiteturais: é possível, mas…

Sim, você pode implementar Clean Architecture, Hexagonal, CQRS e qualquer padrão em Python. Frameworks como Django (opinativo, MTV) e FastAPI (moderno, async, Pydantic) oferecem bases sólidas. Existem bibliotecas para injeção de dependência, validação de tipos e separação de camadas.

Porém, há diferenças fundamentais na experiência de desenvolvimento:

# Python: Injeção de dependência com dependency-injector
from dependency_injector import containers, providers
from dependency_injector.wiring import Provide, inject

class Container(containers.DeclarativeContainer):
    config = providers.Configuration()
    user_repository = providers.Singleton(
        UserRepository,
        connection_string=config.db.connection_string,
    )
    user_service = providers.Factory(
        UserService,
        repository=user_repository,
    )

@inject
def create_user(
    service: UserService = Provide[Container.user_service],
):
    service.create(name="Lincoln")

// C#: Injeção de dependência nativa no .NET
builder.Services.AddScoped<IUserRepository, UserRepository>();
builder.Services.AddScoped<IUserService, UserService>();

// No controller ou endpoint, o framework injeta automaticamente
app.MapPost("/users", (IUserService service) =>
{
    service.Create(name: "Lincoln");
});

A diferença não é apenas de sintaxe — é de filosofia:

• Em C#, a DI é parte do framework. Você não precisa escolher uma biblioteca, configurar wiring, ou decorar métodos. Funciona “out of the box”
• Em Python, a DI é uma biblioteca terceira. Funciona, mas adiciona complexidade, exige configuração e não tem suporte nativo do framework Essa diferença se repete em quase todos os padrões:

Onde Python vence — sem discussão

Há domínios onde Python simplesmente não tem concorrente real:

• IA e Machine Learning: TensorFlow, PyTorch, Hugging Face — o ecossistema inteiro é Python-first
• Ciência de dados: Pandas, NumPy, Jupyter — C# nem aparece na conversa
• Prototipagem rápida: de zero a uma API funcional em minutos com FastAPI
• Scripts e automação: substituir Bash, processar arquivos, interagir com APIs
• DevOps: Ansible, scripts de infraestrutura, ferramentas CLI

Onde C# vence — quando complexidade importa

Para aplicações que exigem manutenção a longo prazo por equipes grandes, com padrões arquiteturais rigorosos, C# (e, de forma mais ampla, o .NET) oferece vantagens reais:

• Refactoring seguro: tipagem estática forte permite renomear, extrair e mover código com confiança
• Compilação como guardião: erros de tipo, interfaces não implementadas e dependências ausentes são detectados antes de executar qualquer código
• DI e middleware nativos: o pipeline do ASP.NET Core é maduro, testável e extensível
• Boundaries forçados: assemblies e projetos separados criam fronteiras arquiteturais reais, não apenas convenções
• Ecossistema enterprise: integração nativa com Azure, SQL Server, Identity, e todo o ecossistema Microsoft

O veredicto

📌 Python e C# não são concorrentes — são complementares.

A pergunta certa não é “Python ou C#?” — é “qual problema estou resolvendo?”

Se o problema é IA, dados ou prototipagem: Python, sem pensar duas vezes.

Se o problema é uma aplicação modular, com camadas, padrões e equipe que precisa de refactoring seguro em dois anos: C# vai te dar menos dor de cabeça.

E se o problema exige os dois? Use os dois. Microsserviço de IA em Python, orquestração e API principal em C# — isso não é heresia, é pragmatismo.

Considerações Importantes

UV Ainda É Pré-1.0

O UV está em versão 0.6.x (março 2026). Apesar de estável para uso em produção e adotado por milhares de projetos, a versão pré-1.0 significa que breaking changes podem acontecer entre releases menores. A Astral mitiga isso com changelogs detalhados e migração assistida, mas é um ponto a considerar antes de adotar em ambientes corporativos conservadores. Acompanhe os releases no GitHub para saber quando a 1.0 chegar.

O pyproject.toml Como Fonte de Verdade

O UV adota o pyproject.toml seguindo as PEPs 517, 518 e 621 — os padrões oficiais do Python para metadados de projeto. Isso significa que seu projeto UV não fica preso ao UV: qualquer ferramenta compatível com essas PEPs (incluindo pip e poetry) consegue ler e usar seu pyproject.toml. Se um dia você precisar migrar, o caminho de saída está garantido.

UV e Docker

Para projetos que rodam em containers, o UV brilha especialmente na etapa de build. Um Dockerfile otimizado com UV:

FROM python:3.12-slim

# Instalar UV como binário estático (sem dependências)
COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv

WORKDIR /app
COPY pyproject.toml uv.lock ./

# Instalar dependências (camada separada para cache)
RUN uv sync --frozen --no-dev

COPY src/ ./src/

CMD ["uv", "run", "uvicorn", "meu_api.main:app", "--host", "0.0.0.0"]

O ganho em tempo de build é brutal — especialmente em pipelines de CI/CD onde cada segundo de execução tem custo real.

UV vs Cargo vs dotnet CLI

Se você vem de Rust ou .NET, vai perceber que o UV segue a mesma filosofia de CLI unificada:

O UV é, para o Python, o que o cargo é para o Rust: a ferramenta que a comunidade esperou por décadas.

Sobre a Adoção e Comunidade

Números que mostram a tração do UV:

• +40.000 estrelas no GitHub (março 2026)
• Adotado pelo FastAPI como gerenciador de pacotes recomendado na documentação oficial
• Integrado ao GitHub Actions como opção oficial para setup de Python
• Suportado oficialmente no VS Code e PyCharm
• Releases semanais com changelog detalhado e semver estrito

Quando Migrar e Quando Esperar

Se você está em um projeto com pip puro e sente a dor da lentidão e da falta de lockfile: migre agora. O custo é baixo — uv pip install -r requirements.txt funciona como drop-in replacement do pip.

Se você está com Poetry e o fluxo funciona sem dor: avalie com calma. A migração vale a pena, mas não é urgente se o projeto já está estável.

Se a empresa exige ferramentas auditadas e versionadas (1.0+): espere a versão 1.0 do UV. Mas acompanhe de perto — ela está próxima.

Conclusão

O UV é, sem exagero, o maior avanço no tooling Python dos últimos anos. Ele resolve um problema que a comunidade arrastava há mais de uma década — a fragmentação absurda de ferramentas para fazer algo que deveria ser simples: instalar pacotes, criar um ambiente e executar código.

Com o UV, você tem uma ferramenta que substitui pip, virtualenv, pyenv, pip-tools, pipx e parte do Poetry. Escrita em Rust, com velocidade absurda e aderência aos padrões PEP. Se você está começando um projeto Python novo, não há motivo para não usar UV.

Quanto ao comparativo com C#: Python é uma linguagem extraordinária para prototipagem, IA, dados e automação. Mas quando a conversa é sobre aplicações enterprise complexas com padrões arquiteturais rigorosos e manutenção a longo prazo, C# (e o .NET) oferece vantagens estruturais que são difíceis de ignorar — tipagem estática forte, DI nativa, compilação como guardião, e tooling de refactoring superior.

A maturidade de uma escolha técnica está em reconhecer: não existe linguagem perfeita para tudo. Existe a linguagem certa para o problema certo. E ter UV no arsenal torna Python significativamente mais viável para projetos sérios — porque a parte que sempre foi ruim (o gerenciamento de pacotes) finalmente ficou excelente.

Referências

• UV — Documentação Oficial
• Astral — Empresa por trás do UV e Ruff
• Python.org — Site oficial do Python
• Python Software Foundation (PSF)
• PEP 20 — The Zen of Python
• Ruff — Linter Python escrito em Rust
• TIOBE Index
• Makefile: Automatizando tarefas para Python, Hugo e Docker — artigo relacionado neste blog
• Padrões GoF: Código à Nuvem, Monólito ao Microserviço — artigo relacionado neste blog 📬

👉 Artigo completo com todos os exemplos de código: pip É Lento, Poetry Complexo: UV Chegou Resolvendo o Python