Em 1º de novembro de 2026, o desenvolvedor Simon Willison publicou no blog uma nota curta e direta. Ela virou regra prática para quem trabalha com Python: na dúvida diante de um erro confuso de dependência, apague o arquivo uv.lock.
O relato parte da experiência dele desde a migração para o Python 3.15.
Willison passou a usar a versão 3.15. Ela trouxe de volta problemas intermitentes na resolução de pacotes em seus projetos.
O que acontece na prática
Willison explica que a maior parte de seus projetos são bibliotecas. Bibliotecas não devem carregar um arquivo uv.lock.
Ele justifica a escolha pela convivência no ecossistema. Travar versões de dependências em uma biblioteca impõe essas versões a qualquer projeto que a utilize.
O arquivo costuma aparecer no.gitignore e não chega a ser commitado nos repositórios.
O arquivo continua existindo localmente. Rodar comandos como uv run pytest deixa um uv.lock para trás.
Esse resíduo pode fixar uma versão de dependência que ainda não tem wheel disponível para o Python 3.15.
O resultado é um erro que parece vir do código do projeto. Ele vem de uma decisão antiga de resolução de pacotes registrada em disco.
O erro do watchfiles e do pyo3
O exemplo citado na nota é específico e ajuda a entender o mecanismo.
Ao tentar construir o pacote watchfiles na versão 1.1.1, o processo falhou na chamada a maturin.build_wheel. A mensagem de erro apontou a causa: a versão configurada do interpretador Python, a 3.15, é mais nova do que a versão máxima suportada pelo PyO3, a 3.14.
O PyO3 é a camada que conecta código Rust ao Python. Dependências com componentes nativos precisam ser compiladas ou ter wheels pré-compiladas para cada versão do interpretador.
Quando o lock fixa uma versão antiga do watchfiles, o ambiente tenta construir um pacote que ainda não acompanhou a nova versão da linguagem.
Apagar o uv.lock e rodar uv run pytest novamente costuma resolver. A nova execução força uma nova resolução de dependências, capaz de escolher versões compatíveis.
Por que o lockfile atrapalha bibliotecas
Arquivos de lock existem para dar reprodutibilidade a aplicações. Eles congelam a árvore exata de dependências para que o ambiente seja idêntico em qualquer máquina.
Em bibliotecas, a lógica é oposta. Quem publica um pacote quer que ele funcione com o maior conjunto possível de versões das dependências.
A decisão final fica com o projeto que o consome.
O atrito descrito por Willison nasce dessa mistura de papéis.
O arquivo gerado durante os testes não é versionado, mas permanece no diretório e passa a influenciar execuções seguintes. É um estado invisível para quem revisa o repositório e difícil de diagnosticar para quem só olha a mensagem de erro.
Um sintoma da transição para o Python 3.15
A nota se conecta a uma publicação anterior do mesmo autor, de 12 de outubro de 2026. Nela, ele comemora a chegada do Python 3.15 e o fim do suporte à versão 3.10.
Toda transição desse tipo impõe um período de adaptação ao ecossistema. Projetos com extensões compiladas, casos de bibliotecas que dependem de Rust ou de outras linguagens, precisam publicar novas wheels e atualizar suas versões máximas suportadas.
É nesse intervalo que erros como o do PyO3 aparecem com mais frequência.
A recomendação de apagar o uv.lock não resolve a causa raiz, que é a defasagem de uma dependência nativa. Ela elimina a camada de decisões antigas que impede o gerenciador de pacotes de buscar uma alternativa viável.
Por que isso importa
Para equipes que desenvolvem bibliotecas e mantêm vários projetos no mesmo computador
