uv é a melhor inovação a surgir no ecossistema Python na última década

(emily.space)

29 pontos por GN⁺ 2025-10-30 | 7 comentários | Compartilhar no WhatsApp

uv simplifica de forma radical a instalação do Python e o gerenciamento de ambientes virtuais, resolvendo os problemas complexos de configuração de ambiente no ecossistema Python
Escrito em Rust, combina velocidade e estabilidade e lida com instalação de versões do Python, gerenciamento de pacotes e resolução de dependências com um único comando
Reconhece automaticamente o pyproject.toml para configurar o ambiente do projeto, e com uv sync é possível reproduzir entre equipes um ambiente de desenvolvimento totalmente idêntico
Com comandos como uv run, uv add e uvx, é possível executar sem ativar o ambiente virtual, além de adicionar pacotes e fazer execuções pontuais
Ao garantir consistência na instalação e na execução do Python, o uv é visto como um ponto de virada que eleva bastante a produtividade dos desenvolvedores e a eficiência da colaboração

Visão geral do uv

uv é uma ferramenta gratuita e open source de gerenciamento de Python desenvolvida pela Astral, com o objetivo de simplificar processos complexos de configuração de ambiente
- A Astral é a equipe por trás de ferramentas de desenvolvimento Python como o Ruff
- O uv oferece instalação de versões do Python, instalação de pacotes, gerenciamento de ambientes virtuais e resolução de dependências, sendo muito mais rápido do que ferramentas existentes
Foi desenvolvido em Rust, tem desempenho excelente e funciona em praticamente todas as plataformas, como macOS, Linux e Windows

Instalação e uso básico

A instalação é muito simples e pode ser feita com uma única linha de comando via curl ou PowerShell
- Linux/Mac: curl -LsSf https://astral.sh/uv/install.sh | sh
- Windows: powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
Como não altera a instalação existente do Python, é possível testar com segurança

Gerenciamento do ambiente do projeto

O uv gerencia automaticamente um ambiente virtual para cada projeto Python e configura o ambiente ao reconhecer o arquivo pyproject.toml
- No pyproject.toml são definidos a versão do Python, a lista de dependências e o nome e a versão do projeto
- Exemplo:
```
[project]  
name = "my_project"  
version = "1.0.0"  
requires-python = ">=3.9,<3.13"  
dependencies = ["astropy>=5.0.0", "pandas>=1.0.0,<2.0"]  
```
- Essa abordagem fornece uma definição de ambiente mais clara e padronizada do que o pip

Criação de novos projetos

É possível criar facilmente um novo projeto com o comando uv init
- Ele cria automaticamente arquivos essenciais como pyproject.toml e README.md
- Oferece diferentes formas de inicialização com opções como --bare e --package
- É possível ver as opções detalhadas com uv init --help

Sincronização de projetos existentes

Se o projeto tiver pyproject.toml, ele pode ser usado imediatamente com o comando uv sync
- Instala automaticamente a versão do Python
- Cria um ambiente virtual no diretório .venv
- Gera o uv.lock, que registra as informações exatas de versão de todos os pacotes
Com o comando uv run, é possível executar scripts Python sem ativar o ambiente
- Ex.: uv run myscript.py, uv run jupyter lab

Gerenciamento de dependências e versões do Python

Com o comando uv add numpy>=2.0, é possível adicionar e gerenciar dependências automaticamente
- Não é necessário editar o pyproject.toml manualmente
Com o comando uv python pin 3.12.9, é possível fixar uma versão específica do Python, garantindo a reprodutibilidade do ambiente

uvx: execução pontual rápida

uvx é um comando que permite executar ferramentas imediatamente, sem configuração adicional de ambiente
- Ex.: uvx ruff, uvx jupyter lab, uvx --with pandas,pyarrow ipython
- Com base em cache, permite reexecução muito rápida e é útil para trabalhos experimentais
Com isso, o desenvolvedor pode montar facilmente um ambiente temporário de execução sem ficar preso a ambientes virtuais

Se isso ainda não te convenceu: uma nota pessoal

Durante o desenvolvimento do The Astrosky Ecosystem, o uv foi adotado para unificar ambientes Python em vários sistemas operacionais
- Isso ajudou todos os desenvolvedores e servidores a usarem instalações de Python e versões de dependências totalmente idênticas
- O uv também gerencia o ambiente Python no GitHub Actions e em servidores de produção
Graças ao uv, desapareceram os problemas de divergência entre ambientes de instalação e teste, e a colaboração entre desenvolvedores ficou mais simples

Conclusão

O uv resolve na raiz a complexidade da instalação e do gerenciamento do Python, permitindo que desenvolvedores colaborem com estabilidade em um mesmo ambiente
Graças à alta velocidade e à estabilidade proporcionadas pelo Rust, o uv é avaliado como “a maior inovação a acontecer no ecossistema Python na última década”

7 comentários

kkksss 2025-11-06

Eu achava que o pdm era quase muito parecido com o uv, mas não se fala muito sobre o pdm.

ztaka 2025-11-02

Tenho usado bastante em ML e Web, e espero que o uv logo se torne uma tecnologia entediante haha

yuntae 2025-10-30

Parece que as postagens sobre uv agora não mudam muito de conteúdo.

pmc7777 2025-10-30

Maven e Gradle também..

doolayer 2025-10-30

Quando vejo um repositório que só tem requirements e não tem pyproject.toml, já parece ultrapassado agora haha;

GN⁺ 2025-10-30

Opiniões no Hacker News

Antes eu ouvia que o tooling de Python já era suficiente, mas agora é satisfatório ver os desenvolvedores Python experimentando um ecossistema baseado em lockfile como npm, cargo ou bundler e percebendo as vantagens
O npm também tem problemas, mas instalações consistentes e arquivos de lock são um conceito realmente excelente
- Não há nada mais assustador do que ter que rodar o projeto Python de outra pessoa
  É surpreendente que o gerenciamento de ambiente tenha sido tão inconveniente por tanto tempo
- Fico me perguntando por que demorou tanto
  Não sei se tantas tentativas fracassaram simplesmente por causa da dificuldade do gerenciamento de pacotes ou se era preciso capital de risco
- Há muito tempo uso pip freeze > requirements.txt e pip install -r requirements.txt
  Se você não usar intervalos de versão, o requirements.txt na prática funciona como lockfile
  Por isso acho um pouco exagerada essa febre atual por “lockfile oficial”
- O npm também passou um bom tempo sem lockfile
  Acho que a chegada do yarn foi um grande fator para o npm melhorar
- Trabalho com desenvolvimento web desde 1998 e acho o PNPM muito melhor que o npm
  É mais rápido, mais eficiente e determinístico
  Para mais detalhes, veja pnpm.io/motivation
Com scripts do uv, foi possível distribuir clientes/servidores MCP em um único arquivo
Texto relacionado: MCP server in a file
Como a maioria dos scripts é de arquivo único, a vida fica muito mais simples se você adicionar isto no topo
#!/usr/bin/env -S uv run --script
Assim o script funciona como um executável independente, e o uv instala automaticamente os módulos necessários
- Do ponto de vista de segurança, esse método tem um certo risco
  porque o autor do script pode esconder dependências maliciosas
  Seria bom ter um recurso de whitelist
- Considerando a data de hoje, dá para fixar versões sem lockfile usando a flag de data máxima de release
  Mas alguns pacotes não têm a data de release detectada (ex.: yaml)
- Para executar, o uv precisa estar instalado, então não é totalmente standalone
- É preciso ter suporte a /usr/bin/env -S, e nos nomes das dependências deve-se usar o nome do pacote de distribuição usado no comando uv pip install
  Isso segue o padrão PEP 723 e o pipx também oferece suporte
- É necessária conexão com a internet, e versões diferentes podem ser instaladas dependendo do estado do repositório
Antes de usar uv, eu não tinha interesse em Rust, mas por causa do uv acabei migrando para Rust o código sensível a desempenho
Eu queria que o conda desaparecesse de vez. Em clusters de ML, os ambientes conda ficam grandes demais e a reprodutibilidade é ruim
- Como alternativa ao conda, recomendaram o pixi, baseado em Rust. Ele reutiliza o resolvedor PyPI do uv
- O conda tem reprodutibilidade se você fixar as dependências, mas os builds são lentos
- Se é um cluster de ML, acho que deveria estar containerizado, então não haveria necessidade de conda
- Tenho curiosidade de saber como o uv faz gerenciamento de dependências CUDA
- Para uma abordagem open source de gerenciamento de dependências de ML em larga escala, veja Metaflow docs e o blog Fast Bakery
Antes eu já estava bem satisfeito com a combinação pyenv + venv + pip + pipx, mas o uv
- tem resolução de dependências muito rápida
- melhorou muito a usabilidade com uv run, uv add etc.
- unificou várias ferramentas em uma só
- também simplificou a instalação do Python
Em vez de ativar o ambiente, é muito mais prático colocar uv antes do comando
O gerenciamento de versões do Python também fica fácil, e há uma sensação de batteries included por projeto
Ainda não sei como será a estabilidade no longo prazo, mas já estou usando por padrão em projetos novos
- Ativar o ambiente é só ajustar PATH e prompt
  Tem gente que não gosta de o uv detectar o ambiente automaticamente
  Não vejo muito o valor do gerenciamento de versões do Python, mas com uv recriar ambientes ficou muito mais rápido
- Colocar uv torna a execução dos comandos mais stateless, o que é conveniente em colaboração
- Uso junto com mise para ativação automática, mas o prefixo uv ainda é útil
- A filosofia do uv é que venv é descartável. Se der problema, basta apagar .venv
- Na verdade, esse tipo de configuração de ambiente é só um problema que “simplesmente deveria funcionar”
Esse post de blog bate quase exatamente com a minha experiência
Houve menos atrito e mais simplicidade
Gostaria que a comunidade Python adotasse o uv como ferramenta padrão
Ferramentas baseadas em Rust mudaram completamente a velocidade de feedback
Mas fico curioso sobre como a Astral ganha dinheiro. Ela recebeu investimento, mas não tem produto pago
- O modelo de receita da Astral é vender software empresarial integrado a ferramentas open source
  Por exemplo: um registro de pacotes interno
  Entrevista relacionada: Entrevista com Charlie Marsh
- Um produto com potencial de virar serviço pago é o Pyx
- A Conda também ganha dinheiro só com acesso a “pacotes com segurança reforçada”
  Se há 10 milhões de desenvolvedores Python, acho que o uv também é perfeitamente monetizável
Pessoalmente, acho type annotations e a remoção do GIL mais importantes do que o uv
O uv ainda está em estágio inicial e também tem inconvenientes. No fim, é apenas mais um gerenciador de pacotes
- Parte do motivo de as pessoas elogiarem o uv é que, na prática, pip e venv já melhoraram graças às PEPs padronizadas
  O novo resolver do pip e o aumento na distribuição via wheels tiveram papel importante
  Texto relacionado: Wheels are faster for pure Python
- No nível da linguagem, a remoção do GIL seria uma mudança maior, mas ainda não há muitos casos de uso realmente úteis na prática
- Type hints já são um recurso antigo, introduzido em 2015
- O uv não é só um gerenciador de pacotes; ele agrega muito valor na simplificação da distribuição
  Também é interessante por ter sido escrito em Rust. É uma estrutura que suporta outras linguagens, como o LLVM
  Do ponto de vista do usuário final, o uv é muito melhor, e se for inconveniente para mantenedores, basta enviar feedback
- Type annotations são boas para documentação, mas têm pouca utilidade prática
  Se surgir um modo estrito, talvez até haja ganho de desempenho, mas isso entra em conflito com a filosofia da linguagem
  Ainda assim, se o conda desaparecer, eu toparia migrar para o uv
Eu não gosto do uv
- Ele tenta fazer coisa demais: substituir pip, pyenv, virtualenv e até ruff de uma vez
- Você precisa usar uv pip, então nem é uma substituição completa
- A compatibilidade com Docker também é fraca
- Há muitas variáveis de ambiente novas, o que aumenta a complexidade
- Não acho estranho ter pyenv, virtualenv e pip separados
  Mas pip e venv também quebram com frequência e ficam mais difíceis de depurar
- Na prática, pip, pyenv e virtualenv são sempre usados juntos, então uma ferramenta unificada faz sentido
  O uv não substitui o ruff
  Nem é preciso mexer nas variáveis de ambiente
- uv pip não chama o pip; ele fornece uma interface compatível
  Na prática, é o uv que substitui o pip
  Fico curioso sobre quais problemas de compatibilidade com Docker exatamente existem
- Gerenciar com uv add, uv sync, uv run é muito mais ergonômico e rápido
  Para mais detalhes, veja a documentação uv dependencies concepts
- Na minha experiência, o uv desempenha bem vários papéis. Fico curioso para saber que problemas específicos você enfrentou

aer0700 2025-11-01

O uv é bom por ser rápido, mas também fico pensando como teria sido se tivessem seguido na direção de melhorar o pip.