Rye: uma experiência Python sem complicações

(rye.astral.sh)

2 pontos por GN⁺ 2024-07-10 | 2 comentários | Compartilhar no WhatsApp

Rye é uma ferramenta de gerenciamento de projetos e pacotes que buscava lidar, em um só lugar, com a instalação do Python, projetos pyproject.toml, dependências, virtualenv e instalação de ferramentas globais
Atualmente, seu desenvolvimento foi descontinuado, e recomenda-se usar o projeto sucessor uv, criado pelos mesmos mantenedores
Usuários existentes podem migrar consultando o guia de migração para uv; o Rye continuará disponível para download, mas não há planos para novas atualizações
A interrupção das atualizações também inclui atualizações de segurança, portanto, em novos projetos ou ambientes de manutenção de longo prazo, deve-se considerar a migração para o uv
A experiência Python integrada que o Rye pretendia oferecer abrangia desde projetos complexos até monorepos, mas o foco de manutenção foi transferido para o uv

Estado atual do Rye

Desenvolvimento descontinuado e recomendação do uv
- Recomenda-se que todos os usuários usem o uv
- O uv é um projeto sucessor criado pelos mesmos mantenedores
- O uv é mantido ativamente e é muito mais usado do que o Rye
- Usuários atuais do Rye podem consultar o guia de migração para uv
- O Rye ainda pode ser usado, mas não há planos para atualizações adicionais
- Atualizações de segurança também não estão planejadas

Funcionalidades que o Rye oferecia

O Rye é uma solução de gerenciamento de projetos e pacotes para Python
Foi criado com o objetivo de ser uma ferramenta completa para usuários de Python
Dentro de uma experiência integrada, ele cobre as seguintes tarefas
- Gerenciamento da instalação do Python
- Gerenciamento de projetos baseados em pyproject.toml
- Gerenciamento de dependências
- Gerenciamento de virtualenv
- Instalação de ferramentas globais
Foi projetado para lidar com projetos complexos e monorepos
O vídeo de apresentação pode ser visto em Watch an introduction

2 comentários

lum7671 2024-07-11

Já faz um tempo, mas depois de usar isto e aquilo,
estou usando o
Introduction - PDM.

Acho que vou precisar experimentar o Rye também.

GN⁺ 2024-07-10

Opiniões no Hacker News

Uma parte significativa do desenvolvimento principal de empacotamento agora está acontecendo no uv e, como o Rye usa o uv internamente, quando o uv melhora, o Rye melhora junto
Por exemplo, recentemente foi adicionada ao uv a resolução universal de dependências, permitindo criar um requirements.txt travado com um único resultado de resolução que funciona em todas as plataformas e sistemas operacionais, não apenas no sistema em execução no momento; a versão mais recente do Rye também dá suporte a isso
https://github.com/astral-sh/uv
Como estou desenvolvendo o Rye e o uv, posso responder se houver perguntas
- Fico curioso para saber se a resolução universal de dependências do Rye/UV funciona corretamente também com o PyTorch, ou se sofre do mesmo problema que o Poetry
  https://github.com/python-poetry/poetry/issues/6409
  https://news.ycombinator.com/item?id=39257501
- Gostaria de saber se há algum trabalho ou plano que eu possa acompanhar para arquivos de lock multiplataforma
  Esse é um dos motivos pelos quais a equipe da qual faço parte hesita em migrar. Como fazemos trabalho de ML, tomando como exemplo um projeto baseado em PyTorch, o estado desejado seria colocar todas as dependências no pyproject.toml e, em um Mac AArch64 ou em uma workstation Windows AMD64, gerar arquivos de lock para as seguintes configurações de plataforma: Mac usando o PyTorch MPS padrão, Windows usando PyTorch CUDA, Linux AArch64 usando PyTorch CPU, Linux AMD64 usando PyTorch CPU, Linux AMD64 usando PyTorch CUDA
  Obrigado por criar o Ruff; estou muito satisfeito tanto com o linting quanto com a formatação
- Excelente trabalho. Antes, às vezes eu precisava configurar o ambiente de trabalho de um projeto em um computador novo, e pyenv+venv+pip sempre era doloroso; agora migrei para o Rye
  Hoje é só instalar o Rye, baixar do GitHub e digitar rye sync, e pronto
- Se você está responsável tanto pelo uv quanto pelo rye, fico curioso por que manter os dois ao mesmo tempo. Para evitar a confusão causada pela fragmentação e pelo peso da escolha, não seria melhor encerrar o rye agora?
- Muitas empresas que valorizam builds previsíveis e performáticos estão migrando, e nesse processo passa a ser frequentemente necessário gerar SBOMs para inserir em ferramentas como o guac
  https://guac.sh/
  https://pypi.org/project/sbom4python/ https://github.com/CycloneDX/cyclonedx-python
  Graças ao recurso recém-adicionado de desfazer o pinning de dependências, dá para incentivar a manutenção da compatibilidade durante o desenvolvimento e gerar um requirements.txt exato e explícito para reprodutibilidade, o que torna as etapas de gestão de vulnerabilidades e SBOM muito mais fáceis do que com ferramentas como o Poetry
  Por motivos parecidos, estou usando https://hatch.pypa.io/latest/why/, e também gosto do fato de ele combinar bem com o uv
O ponto que me deixava receoso em relação ao Rye era ele recomendar fortemente o uso de builds não padrão do Python
A página de filosofia (https://rye.astral.sh/philosophy/) explica que os builds do CPython do python.org são totalmente inadequados, que dependendo da plataforma há apenas instaladores .msi ou apenas tarballs, e que várias distribuições do Python divergem muito, criando todo tipo de problema para o subecossistema. Por isso, o projeto usa os builds standalone do indygreg e diz esperar que, algum dia, surja um build de Python bem mantido e confiável para substituir a confusão atual
As informações sobre esses builds do indygreg estão em https://gregoryszorc.com/docs/python-build-standalone/main/, e também é possível escolher outro Python: https://rye.astral.sh/guide/toolchains/
Dito isso, eu quase nunca passei pelos problemas que eles mencionam. O build oficial do Python baixado do python.org funcionou, o Python comum instalado pelo gerenciador de pacotes da distribuição funcionou, e o Python incluído nas imagens oficiais de contêiner Docker também funcionou
Esses builds especiais provavelmente também funcionam bem, mas a falta de padronização me deixa hesitante. Há até uma lista de peculiaridades de comportamento, e não entendo por que adicionar peculiaridades a algo que não está com problema. O fato de a filosofia do Rye ser tão entusiasmada em usar esse build também o torna menos atraente em comparação com alternativas que usam por padrão o Python já presente no sistema operacional
- Talvez ele esteja falando de situações como esta: você trabalha em uma empresa que usa algo como um CentOS antigo, o gerenciador de pacotes do sistema não oferece nada mais recente que Python 3.6, e os binários oficiais do python.org imprimem, ao serem executados, um erro indecifrável sobre a versão da glibc
  Para compilar o Python a partir do código-fonte, são necessárias novas dependências de sistema e muito tempo, e no fim aparece outro erro ainda mais obscuro sobre um arquivo de cabeçalho ausente. Ao pesquisar esse erro, surge uma flag de ./configure que contorna um problema corrigido pelo GCC upstream em 2017 e, de algum modo, você consegue concluir
  Se você nunca passou por esses três erros nem por um ambiente de build manylinux, evitou por completo um mundo de sofrimento. O mesmo vale para scripting de instalação no Windows ou para partes daquela página como “limitar as instruções de CPU disponíveis”
- Há dois extremos em builds, empacotamento e distribuição de Python. Um é o caminho real; o outro é um corredor com mil lâminas. Se a proposta de um Python portátil não faz sentido para você, é porque teve sorte e continuou no caminho real
Baixam regularmente o código-fonte do Python, compilam com otimizações padrão de produção e instalam em /use/local/python${version}; isso funciona de forma muito consistente desde 2018, quando saiu o Python 3.7
Pela minha experiência, esses comandos são tão estáveis e consistentes que dá até para automatizar. Fico curioso para saber qual é exatamente o ponto que o autor está criticando, ou qual é a reclamação fundamental
- A frase “os builds do CPython do python.org são completamente inadequados” talvez signifique que não há binários para macOS/Windows nas releases de segurança de versões antigas do Python
  Por exemplo, não dá para baixar o instalador do Python 3.10.14; o último instalador para Windows é o Python 3.10.11, de 5 de abril de 2023
- Concordo. O correto seria apoiar a PSF; é uma posição estranha defender um novo “jeito certo”
Gosto do Rye. Ele faz exatamente o que se propõe, realmente torna agradável todo o processo de venv/versão do Python/empacotamento e, para quem está acostumado ao modo oficial de usar Python, como pyproject.toml, parece quase transparente
Além disso, ele faz Python parecer Cargo, e Cargo também é uma ferramenta boa de usar
- Se, como eu, você ignorou coisas do tipo Poetry e ficou no pip-tools, o uv usado internamente pelo Rye é uma substituição direta
  Pessoalmente, acho que o pip-tools tinha um desenho muito melhor que Poetry ou Pipenv. Ele era ortogonal tanto ao pip quanto ao virtualenv, e ambos já fazem parte do fluxo do Python há muito tempo. Dá para ver o Rye como um caso em que uma abordagem aderente aos padrões, refinada iterativamente, acaba vencendo
  Além dos ganhos de velocidade por causa do Rust, gosto do fato de ele oferecer bons padrões para onde colocar o ambiente virtual (.venv) e para como instalar várias versões do Python. Parece pequeno, mas depois que wheels resolveram o problema de instalação do numpy, esses padrões sensatos e um pip-tools embutido eram basicamente tudo o que faltava. Nesse sentido, também fico curioso sobre qual passou a ser a razão de existir do Anaconda depois do surgimento dos wheels binários
- Comecei ouvindo que em Python havia uma única maneira de fazer tudo, mas a experiência de instalação e gerenciamento de ambientes era uma bagunça
  Fico feliz em ver que finalmente está melhorando
- Se ele “faz Python parecer Cargo”, isso já me convence na hora. Eu estava pensando em testar o pixi porque o Poetry passava o dia inteiro e ainda não conseguia resolver as dependências
  Parece que existem mais gerenciadores de pacotes Python do que apps de chat do Google
- Fico curioso sobre o que significa “realmente torna agradável”. É difícil demais resumir? No Anaconda ou no Poetry, não consegui identificar muito bem quais partes da experiência de usuário pareciam escolhas especialmente boas
  E, no aspecto de curadoria, a sugestão de confiar em uma organização pequena em vez de organizações maiores e mais antigas parece difícil de convencer. Ou seja, fico curioso sobre o que exatamente ele se propõe a fazer. O que consigo ler é algo como “um bom gerenciador de pacotes é bom, rápido e bom”, então seria bom ter uma página de comparação ou de filosofia
O cinismo do HN às vezes surpreende
Gosto do Rye. Depois de usar gerenciadores de pacotes de outras linguagens, como Cargo ou Hex, eu sempre senti falta de um sistema parecido no Python, e o Rye resolveu totalmente essa necessidade. Para quem não quer instalar várias ferramentas para gerenciar venv, versões do Python e dependências de projeto, é muito bom ter tudo resolvido só com o Rye
- Fico curioso se você já usou conda. Como o Rye se compara ao conda?
  Ainda não tenho uma noção do Rye, mas o conda também consegue gerenciar bem venv, versões do Python e dependências de projeto
- Concordo. O Rye tem funcionado bem para mim. Eu queria um Cargo para Python e, até agora, do meu ponto de vista, o Rye conseguiu isso
Encontrar um novo gerenciador de dependências para Python é como esbarrar em um novo framework JavaScript
- Minha filosofia é simples. Se precisa ser um programa distribuível, eu simplesmente uso Go; se não precisa de nada como portabilidade, uso Docker; e, se a equipe de TI ou alguém te entrega uma máquina com o sistema operacional e a versão do Python que todo mundo na organização usa, aí você usa venv
  Se você precisa lidar com portabilidade, distribuir um programa ou lidar com bibliotecas que dependem de C ou de componentes do sistema operacional, é melhor começar a fazer consultoria em que, depois de receber, você não precise manter a base de código nem se responsabilizar por ela
- Exato. O Docker já resolveu, cerca de 10 anos atrás, o problema de distribuir e executar programas Python
  Hoje em dia dá até para rodar CUDA e PyTorch no Docker. Em threads como esta, quando alguém diz “é só usar Docker”, a resposta comum costuma ser “não quero aprender Docker”, mas, mesmo sem nenhuma experiência com Docker, leva uns 10 minutos para subir um contêiner Python
- Sim. Mas, ao contrário de coisas como Poetry, este aqui é realmente bom
- É realmente grave. Do ponto de vista do usuário, é frustrante que, depois de tantos anos, ainda não exista um padrão
O pixi(https://pixi.sh/latest/) é bom. Ele permite fixar a versão do Python e instalar pacotes a partir do conda e do PyPI, e é escrito em Rust
- Parece interessante, mas é difícil sentir vontade de investir seriamente em mais um ecossistema. Incomoda essa forma de mandar baixar com curl, passar para o bash via pipe e, em seguida, dar eval na saída de um comando arbitrário
- Obrigado pelo link. Fico curioso se é mais rápido que o conda
- O pixi é excelente. Para quem usa conda, o pixi pode servir como substituto do conda com ambientes vinculados ao Git/diretório do projeto, parecido com devbox/devenv/flox
  O contexto é um pouco complexo. A empresa Anaconda tinha o conda, escrito em Python, e o conda-forge, ecossistema open source, é um canal conda com bots de build de CI. Depois, sob o mesmo guarda-chuva do conda-forge, surgiu o mamba, escrito em C++, como substituto do conda; ele é um verdadeiro substituto drop-in, a ponto de alias conda=mamba dever funcionar. Hoje, o próprio conda usa libmamba como resolvedor para ganhar velocidade
  Depois, o autor do mamba separou isso no pixi e reescreveu em Rust, mudando a filosofia sobre o local dos ambientes e a forma de ativação, mas mantendo compatibilidade total com ambientes conda

O conda sempre deu suporte à instalação de pacotes do PyPI via pip em casos como quando eles não estão nos canais do conda, e o pixi dá suporte a pacotes do PyPI por meio do uv. Por isso o pixi é rápido. Segundo o post do blog, há outras otimizações que o tornam muito mais rápido até do que o mamba
Se você usa pacotes que não são Python puro, o caminho certo é a família conda. A escolha do gerenciador de pacotes (conda/mamba/pixi) é secundária
O problema do PyPI é a falta de um papel de guardião. Isso se soma à falta de uma forma padronizada de empacotar pacotes que não são Python puro, fazendo com que o ambiente vaze ou, especialmente quando se distribui apenas o código-fonte e se fazem coisas estranhas no setup.py, como incluir até o compilador para fazer bootstrap do ambiente, tornando tudo irreproduzível
Do lado do conda, o canal conda-forge faz um controle de qualidade bastante bom. Ele verifica restrições, licenças, problemas de arquivos de licença ausentes nas distribuições do PyPI, isolamento de ambiente etc. Claro que não é perfeito, pois os mantenedores podem usar um bot oficial que faz merge automático de mudanças do PyPI com restrições de versão incorretas
O problema que nenhuma ferramenta resolve hoje é centrado no PyPI. É preciso lidar com pacotes que não estão no conda, e os releases de pacotes também são, na prática, forçados a sair primeiro no PyPI
Mesmo ao instalar via conda um pacote que existe apenas no PyPI, algumas de suas dependências podem estar no conda. Até onde sei, não há gerenciador de pacotes que use pacotes do conda para satisfazer dependências de pacotes do PyPI. É possível adicionar manualmente pacotes do conda para satisfazer dependências, mas há o risco de não receber as restrições de versão corretas
Mesmo ao escrever um pacote Python open source, na maioria dos casos você precisa, ou deveria, lançá-lo primeiro no PyPI, ainda que a configuração dependa apenas de canais do conda. Isso porque releases no canal conda-forge, na prática, exigem a existência no PyPI. Por isso, mesmo para alguém como eu, o Rye ainda pode ser útil e vale a pena dar uma olhada

Vale saber que o pessoal do uv (https://astral.sh/blog/uv) assumiu o comando deste projeto do Armin
A página de introdução diz: “Rye is still a very experimental tool, but this guide is here to help you get started.”
Estou bem animado com este projeto, mas pretendo esperar até que ele chegue a um estágio mais maduro. Gosto de todas as outras coisas que a equipe da Astral lançou, então minhas expectativas são altas
Estamos usando rye no desenvolvimento da biblioteca openai-python, e tem sido muito bom
O Rye parece bom, e também usei Poetry com bastante satisfação, mas passei a respeitar muito a qualidade das ferramentas padrão do Go
Sempre que começo um projeto Python, sinto que preciso reaprender o estado atual do gerenciamento de dependências/ambientes virtuais