Rye e uv: agosto é temporada de colheita do empacotamento Python
(lucumr.pocoo.org)- Depois que a manutenção do Rye passou para a Astral em fevereiro de 2024, o uv, seu resolver e installer subjacente, evoluiu rapidamente e surgiu como candidato à unificação das ferramentas de empacotamento Python
- As versões mais recentes do uv agora incluem manipulação de
pyproject.toml, suporte a workspaces, referência a pacotes locais, instalação de scripts e até gerenciamento da instalação do Python, absorvendo áreas antes cobertas pelo Rye - Com o aumento de novos usuários de Python impulsionado por investimentos em IA e ML, a experiência do desenvolvedor ainda segue inconsistente por causa da grande quantidade de ferramentas de empacotamento e da compatibilidade irregular entre elas
- O ecossistema de empacotamento precisa de uma ferramenta dominante usada por todos para concentrar investimentos e documentação em uma única stack, e o Rye tem grande chance de servir como caminho de migração para uma transição centrada no uv
- O investimento de VC na Astral é um risco que a PSF e os projetos centrais de Python precisam considerar, mas o uv é avaliado como um código que, no pior cenário, ainda pode ser bifurcado e mantido
O movimento de concentração de funcionalidades do Rye no uv
- Em fevereiro de 2024, a manutenção do Rye passou para a Astral, e nos meses seguintes a Astral melhorou rapidamente as ferramentas de empacotamento Python
- Usuários do Rye puderam perceber que o uv, o resolver e installer subjacente, ficou melhor e mais rápido
- As versões atuais do uv começaram a oferecer diretamente recursos que antes exigiam o Rye
- manipulação do arquivo
pyproject.toml - suporte a workspaces
- referência a pacotes locais
- instalação de scripts
- gerenciamento da instalação do Python
- manipulação do arquivo
- Quem usa Rye hoje precisa olhar de perto o uv e enviar feedback para a Astral
Por que as ferramentas de empacotamento Python precisam convergir
- A apresentação na EuroPython Prague foca na situação atual do empacotamento Python e nas lições aprendidas ao criar o Rye
- O objetivo de uma ferramenta de empacotamento é se tornar a ferramenta dominante nesse espaço
- a ferramenta usada por todos deve ser a melhor ferramenta
- porque é ela que quem está conhecendo Python pela primeira vez encontra ao começar sua jornada de programação
- Nos últimos dois anos, o Python se tornou uma plataforma extremamente quente e popular entre novos desenvolvedores, impulsionado por investimentos e interesse em IA e ML
- É importante que novos usuários se lembrem do Python não como uma linguagem antiga com ferramentas ruins, mas como uma linguagem com excelente experiência de desenvolvimento
- Mas hoje o empacotamento Python ainda tem opções demais, a compatibilidade entre ferramentas não é completa, e as inconsistências espalhadas pela stack prejudicam a experiência
- alguns usuários seguem uma ferramenta até baterem numa parede, migram a stack inteira para conda e depois acabam voltando
O potencial do uv para se tornar a ferramenta dominante
- Quando uma ferramenta ocupa uma posição dominante, isso significa que a maior parte dos investimentos se concentra em uma única stack
- Para o Rye e várias ferramentas ao seu redor, o ideal é que deixem de precisar existir de forma independente quando uma ferramenta dominante estiver estabelecida
- Hoje, o uv é avaliado como a ferramenta com maior chance de assumir esse papel
- ele ainda não cobre todos os casos de uso
- mas parece caminhar rapidamente para isso
- Este é o momento de a comunidade começar a se reunir em torno do uv
- Isso não significa que ele será a única ferramenta para sempre
- ferramentas podem surgir e desaparecer
- no futuro, outra ferramenta pode aparecer
A aposentadoria do Rye e a mudança na orientação para projetos Python
- A versão final esperada do Rye deve aposentar os recursos exclusivos do Rye, migrar os usuários para o uv e funcionar, em grande parte, como um alias do uv
- Aposentar apenas o Rye não é suficiente
- hoje, várias soluções de gerenciamento de pacotes ainda são usadas no Python
- a comunidade precisa orientar para um número menor de ferramentas
- Rye e uv foram construídos sobre muitos anos de evolução do ecossistema abaixo deles
- a transição de
setup.pypara eggs e depois para wheels - a passagem da ausência de padrões de metadados para um estado com padrões definidos
- a migração de sistemas de build acoplados para sistemas de build desacoplados
- o trabalho que tornou possíveis binários Python redistribuíveis e baixáveis
- o ecossistema relacionado de crates em Rust e bibliotecas Python
- a transição de
- A comunidade precisa se preparar para dizer, em algum momento, que certas ferramentas não serão mais recomendadas
- no passado, documentos de orientação para novos desenvolvedores recomendavam
ez_setup.pyeeasy_install - depois,
ez_setup.pyfoi removido desses guias e substituído porpip - alguns projetos passaram a orientar
pip-tools,poetryePDM - hoje, muitos projetos chegam a mostrar 5 instruções de instalação ao mesmo tempo por causa da variedade de ferramentas
- no passado, documentos de orientação para novos desenvolvedores recomendavam
- Mantenedores de projetos Python importantes precisam testar o uv diretamente e avaliar se podem recomendá-lo aos usuários
- O texto do Charlie, da Astral, sobre o que o uv já consegue fazer hoje mostra o estágio atual alcançado pela ferramenta
O investimento de VC na Astral e o risco para a comunidade
- O fato de a Astral, criadora do uv, ser uma empresa com investimento de VC é um ponto inevitável de debate
- Do ponto de vista da comunidade, o fato de alguém injetar muito dinheiro pode criar novos desafios
- A PSF e os projetos centrais de Python precisam levar isso em conta
- Observando o código e o comportamento do uv, ele parece algo que, mesmo no pior cenário futuro, pode ser bifurcado e mantido
- Mesmo que a Astral feche as portas ou faça algo muito suspeito em termos de licença, a comunidade ainda pode ficar em uma posição melhor do que antes da existência do uv
1 comentários
Opiniões no Hacker News
A versão mais recente do uv também foi discutida ontem: https://news.ycombinator.com/item?id=41302475
O texto linkado é a opinião escrita pelo autor do Rye depois de ver esse lançamento
Para quem tem interesse no uv, usar uv em vez de pip acelerou bastante o processo de lançamento do Home Assistant
O tempo de lançamento caiu de cerca de 2,5 horas para cerca de 20 minutos, e os detalhes estão em https://developers.home-assistant.io/blog/2024/04/03/build-i.... Para constar, sou apenas usuário do HA
Uso Python só de forma leve, mas não sei o que diabos ele fazia para demorar tanto, e isso me parece absurdo
Sei que há problemas no empacotamento em Python, mas pessoalmente cheguei bem longe até agora só com plain pip
A maior mudança foi trocar o virtualenv original pelo módulo venv embutido. Se eu fosse levar gerenciamento de dependências realmente a sério, acho que faria um monorepo no estilo FAANG e evitaria as dores de cabeça relacionadas ao gerenciador de pacotes
Gerencio um monorepo Python em ambiente de produção e o gerenciamento de dependências é um inferno. Estou tentando aplicar alguns recursos novos do Poetry, mas o estado do ecossistema em torno de monorepos grandes é horrível
O objetivo não é “para mim basta”; precisamos de uma ferramenta padrão para pacotes e ambientes virtuais que escale de uma organização com 2 desenvolvedores Python até centenas ou milhares de pessoas. Caso contrário, o ecossistema se fragmenta, bugs e documentação difícil aumentam, e fica complicado para a linguagem continuar evoluindo de forma eficaz
Mas não há como definir para qual versão do Python um projeto foi criado. Se você está criando um pacote, é bem provável que precise testá-lo em várias versões; e, se não for um pacote distribuível instalável, mas sim um conjunto de código compartilhado por alguns desenvolvedores, para tarefas como executar modelos de machine learning, implantar cloud functions ou gerar relatórios, normalmente você vai querer mirar exatamente uma única versão do Python
Também fico em dúvida se a abordagem de monorepo significa copiar numpy e pandas para dentro do repositório
No começo, eu esperava que a nova ferramenta resolvesse os problemas de “empacotamento” do Python, mas, lendo mais, vi que era mais sobre gerenciamento de pacotes do que sobre empacotar uma aplicação Python que eu criei
Pessoalmente, nunca tive grandes problemas com gerenciamento de pacotes em Python e, embora haja lacunas no ecossistema, salvo coisas como a ausência de namespaces, o pip em geral funciona bem
O que realmente irrita é não conseguir embrulhar facilmente uma aplicação Python como um executável e distribuí-la em algum lugar. Vejo com frequência, em produção, gente fazendo git clone e criando virtualenv, o que exige conectividade além do necessário no servidor de destino e também deixa dependências de desenvolvimento no sistema operacional. Do ponto de vista de segurança, é uma péssima ideia; então, enquanto esse problema não for resolvido, vou preferir outras linguagens para trabalhos que precisem ser distribuídos a usuários finais ou implantados em produção
Para isso, a aplicação precisa ser entregue ao usuário, encontrar o Python ali, e esse processo deve ser transparente para o usuário. Ao criar o Rye, e também no caso do uv, uma das razões foi tentar dar suporte à instalação do Python de uma forma que não quebrasse o sistema
Uma forma mais avançada seria automatizar o processo inteiro, incluindo o uv. Mesmo hoje, se quiser, você pode usar um instalador curl to bash para instalar uv/Rye e o app em um local temporário específico do app, garantindo que o sistema do usuário nunca seja quebrado
Seria bom se um dia esse processo fosse totalmente transparente, sem exigir acesso à rede, e também oferecesse algo como um .msi para Windows. Mas a premissa para isso é que uma ferramenta como o uv consiga posicionar arbitrariamente um Python pré-compilado e todas as dependências necessárias em locais adequados à plataforma do usuário
O bônus final que o uv talvez possa oferecer algum dia é um artefato completamente empacotado, e isso seria muito bom. Mesmo a etapa anterior já pode tornar a experiência de entregar ao usuário uma ferramenta de linha de comando feita em Python algo que deixe de ser horrível. Dá para usar uvx ou, se quiser, esconder completamente o próprio uv
Por exemplo, há ferramentas que criam instaladores por sistema operacional, e também surgiram ferramentas para distribuir em lugares mais incomuns, como Android, iOS ou navegadores. Naturalmente, um pacote específico pode não funcionar em um destino específico, mas, como há uma interface padrão, se o código puder ser executado em algum lugar, a ferramenta para esse destino deveria conseguir produzir um resultado que funcione ali
Depois do rug pull do npm baseado em venture capital e da aquisição pela Microsoft, e depois que a OpenAI mostrou que até o status legal de organização sem fins lucrativos não passa de marketing sem força para líderes envolvidos em rotas de venture capital, fico relutante em entregar a infraestrutura de linguagem que está no caminho crítico a esse tipo de organização.
As pessoas que contribuem ali são, individualmente, ótimas e muitas vezes brilhantes, mas os interesses financeiros no nível da organização já nascem contaminados. Depois de 1 a 4 anos, o que importa é a organização. É aquela coisa de “morrer como herói ou viver o bastante para se tornar o vilão”.
Por isso, linters rápidos, checagem de tipos, varredura de código e ferramentas auxiliares de PR são aceitáveis e podem ser trocados a qualquer momento. Mas o fluxo de instalação e o repositório de pacotes, não.
Considerando o estado do pip e do conda, é lamentável, mas acho que essa é a realidade.
Acho que a Microsoft é dona do Python, só não deixa isso publicamente explícito.
Alguns anos atrás eu queria criar bindings Python para o kubectl, mas descobri que, para funcionar de forma multiplataforma, o CGo precisava usar o mesmo compilador que o Python em todas as plataformas. Só que, no Windows, o CGO usa MINGW e o Python usa MSVC. Perguntei na lista de discussão de desenvolvimento do Python que existia na época por que um projeto “open source” usava um compilador proprietário, e a resposta foi que o MSVC era uma escolha histórica e que agora não dava para mudar. A explicação foi que a Microsoft fornece à Python Foundation infraestrutura gratuita para rodar CI e builds, além de fornecer desenvolvedores que trabalham no interpretador Python. Ou seja, funcionários da Microsoft são pagos com dinheiro da Microsoft para trabalhar no interpretador Python e recebem orientação para não remover ferramentas da Microsoft da cadeia de ferramentas.
A situação piorou a cada ano. Como em projetos parecidos, o sucesso criou terreno para que pessoas sem grande mérito assumissem poder, e a Python Foundation e projetos adjacentes como a PyPA começaram a ser ocupados por pessoas que chegaram a posições não por contribuir com código útil, mas escrevendo páginas de código de conduta. As disputas intermináveis em torno desse código de conduta e do controle de cargos acabaram levando contribuidores antigos a sair ou a serem expulsos; recentemente, até Tim, criador do Tim sort, foi banido.
A Microsoft continua empurrando a agenda habitual que leva a todo projeto em que toca: adicionar um monte de recursos inúteis para fins de marketing, fazer o projeto oscilar em todos os sentidos e, em especial, fazê-lo seguir modas o máximo possível. Assim, embora Python seja uma linguagem com um sistema de tipos completamente diferente, eles tentam adicionar o máximo possível de tipagem ao estilo de machine learning; e, embora seja uma linguagem usada em boa parte para acoplar dinamicamente bibliotecas nativas, ela fica obcecada com pré-compilação e JIT. No fundo, é como transformá-la em um C# sem chaves.
A Microsoft é inteligente o suficiente para saber que, se anunciar publicamente a posse do Python, muita gente vai se afastar da tecnologia, então não faz grande propaganda disso. Mas continua fazendo desenvolvedores dependerem de suas ferramentas e, em algum momento, virá cobrar esse investimento.
Mas, até agora, o que produziram foi essencialmente bilhões de posts de blog de contribuidores dizendo algo como “o sistema que criamos nos impede de ser úteis, e, de todo modo, isso não é culpa nossa”.
Parecem tão mergulhadas em sistemas internos e política interna que nem sabem mais por que estão ali.
Então, se alguém de fato executar bem e dominar o mercado como a Astral, esse é exatamente o resultado que nós, como comunidade, merecemos.
[1]: O que quero dizer aqui é política interna. Não é aquele chilique esquisito de extrema direita do tipo “contratação DEI!”.
Essas ferramentas ainda têm o problema da autoridade.
Isso as torna diferentes do cargo, porque não foram aprovadas pela PyPA. Ao mesmo tempo, a PyPA não conseguiu entregar uma solução abrangente por anos, enquanto o empacotamento em Python e as ferramentas de desenvolvimento continuaram se multiplicando. Há apenas 3 ou 4 anos, poetry e pipenv pareciam resolver problemas de empacotamento em Python que pip+virtualenv não resolviam.
Agora acho que a PyPA deveria embarcar no navio da astral.sh, mas não sei se faria isso sem algum nível de controle.
Na minha visão, aquilo teve muito a ver com relações pessoais, e o Pipenv era desastroso na época. A intenção era boa, mas, na empresa, mesmo em repositórios com relativamente poucas dependências amplamente usadas, era preciso esperar uma hora para atualizar o arquivo de lock. Simplesmente não funcionava.
Na prática, sou muito grato pelo trabalho técnico difícil que a PyPA faz. Mas não me importo muito com o conjunto de ferramentas que ela recomenda hoje. Acho melhor usar o que a comunidade usa e não se preocupar com propostas “oficiais”.
Não está claro quantas pessoas participam, nem em que medida a PyPA está ligada ao Python core ou à PSF.
Acho que um endosso realmente útil viria do próprio projeto core do Python. Num mundo ideal, o tutorial oficial de Python começaria com “é assim que se instala Python”, orientando primeiro a instalar o uv, do mesmo modo que a documentação oficial do Rust aponta para rustup e cargo.
Espero muito que a PSF estabeleça algum tipo de relação com a Astral para que um dia essa realidade seja possível.
Acho que ela mesma provou ser, em grande parte, irrelevante nesse contexto. Tudo em que toca parece apodrecer, então, por mais lamentável que seja, eu gostaria que ficasse longe desse problema. Dói dizer isso e vai contra a minha filosofia, mas é apenas um julgamento que reflete o estado atual. Trabalhei em tempo integral com Python por 10 anos, e outros ecossistemas de empacotamento já ultrapassaram Python por pelo menos uma volta inteira.
Agora nem me importo mais com nuances como “é um problema de execução da PyPA ou o escopo de papel definido está errado”. Também estou cansado de ser arrastado para esse tipo de discussão.
Armin defende que o uv domine essa área, mas também reconhece que, por ser financiado por venture capital, pode haver um rug pull
Como solução para esse problema potencial, ele diz que “é muito fácil fazer um fork”, mas forks não geram, por natureza, ainda mais fragmentação? Justamente o problema que ele quer resolver
Acho que uma ferramenta que pretende dominar o cenário de empacotamento do Python deveria ser liderada e controlada pela comunidade
O nível de fragmentação depois de uma ferramenta que sofreu rug pull já ter unificado o ecossistema pode ser muito menor do que antes da unificação
E essa comunidade imaginária vai precisar de mais algumas décadas para criar uma ótima ferramenta dominante?
Hoje de manhã, no trabalho, dei uma olhada em migrar nosso software do Poetry para o uv por causa da lentidão do Poetry
Até agora li bastante documentação, mas não avancei muito na prática. Eu também fiz a migração anterior para o Poetry, e aquela foi bem mais simples. Pelo que vi até agora, o Poetry tentou criar um gerenciador de pacotes simples que se comporta como outros gerenciadores de pacotes, enquanto o uv parece preservar boa parte da loucura dos pacotes Python
Também não acontece de uma mudança pequena no Poetry quebrar o formato do package.toml, nem de a resolução em múltiplos índices ficar mais lenta por causa de “sources” idiotas que não funcionam para dependências transitivas
O uv parece basicamente se encaixar no fluxo de ferramentas Python padrão
Eu não culparia ninguém por pular esta rodada e esperar pela edição de 2026 de “Gerenciador de pacotes Python: agora resolvemos de verdade!”
Ainda assim, continuo sendo um usuário satisfeito do Nix
Gosto muito desse enquadramento
Graças ao trabalho que muitas pessoas acumularam gradualmente ao longo de muito tempo, chegamos agora a um ponto em que algumas pessoas em uma empresa conseguem melhorar drasticamente a situação com um esforço moderado