PYX: o próximo passo no empacotamento Python

• pyx é um registro de pacotes nativo de Python criado pela equipe de desenvolvimento do uv, que aumenta em até 10x a velocidade de instalação a partir de fontes como PyPI, PyTorch e repositórios privados
• Indo além do escopo dos registros de pacotes tradicionais, ele oferece recursos de velocidade, segurança e reconhecimento de GPU, com suporte tanto a pacotes internos quanto a fontes públicas como PyPI e PyTorch
• Fornece URLs de índice dedicadas que podem ser filtradas por critérios como popularidade do pacote, data de criação e presença de vulnerabilidades, reforçando segurança e conformidade
• Com suporte aos padrões mais recentes específicos de Python e integração direta com o uv, permite autenticação e uso sem configuração
• Resolve principais problemas de ambientes corporativos — como builds duplicados dentro da equipe, dificuldade de instalação de PyTorch e CUDA, quebras de build e inconveniência na autenticação — por meio da integração entre servidor e cliente
• Com reconhecimento de GPU, fornece versões pré-compiladas de PyTorch, vLLM, FlashAttention e DeepSpeed adequadas ao hardware, com metadados consistentes e configuração otimizada
• Oferece desempenho muito superior ao de outros registros privados por meio de artefatos otimizados e da API nativa de metadados do uv

---

A visão e o contexto da Astral

• A Astral é uma empresa que cria ferramentas de desenvolvimento de alto desempenho para o ecossistema Python, conhecida por Ruff (linter/formatador) e uv (gerenciador de pacotes)
• A motivação para fundar a empresa veio da percepção de que, apesar de Python ser a linguagem de programação mais popular do mundo, ela não vinha recebendo suporte suficiente em tooling
• Atualmente, a cadeia de ferramentas da Astral ultrapassa 100 milhões de instalações por mês, e o uv processa mais de 500 milhões de requisições por dia, em crescimento explosivo
• O objetivo é tornar Python o ecossistema de programação mais produtivo, e para isso a empresa quer construir a nuvem do Python, indo além das ferramentas cliente

Apresentando o pyx

• pyx é um registro de pacotes nativo de Python projetado como backend otimizado para o uv
  • Pode hospedar pacotes internos
  • Atua como frontend acelerado e configurável para fontes públicas como PyPI e o índice do PyTorch
• Principais características
  • Alta velocidade de instalação: otimização da instalação e da compilação de pacotes
    • Usa artefatos otimizados e a API nativa de metadados do uv ao instalar pacotes a partir de PyPI, PyTorch e fontes privadas internas
    • Entrega velocidade até 10x maior que a de outros registros privados
  • Segurança e conformidade reforçadas: minimização de riscos por meio do entendimento de dependências e da cadeia de suprimentos
    • Permite criar URLs de índice dedicadas para filtragem de pacotes
    • Controla o acesso a pacotes com base em critérios como popularidade, idade da publicação e status de vulnerabilidades
    • Garante builds reproduzíveis no lado do servidor
  • Suporte aos padrões mais recentes
    • Suporta os padrões e workflows de empacotamento mais recentes, específicos de Python
    • Integra-se diretamente ao uv, permitindo autenticação e uso contínuos sem configuração adicional
  • Distribuição de pacotes com reconhecimento de GPU: simplifica builds e distribuição relacionados a CUDA e PyTorch
    • Fornece pré-builds personalizados para bibliotecas relacionadas a GPU, como PyTorch, vLLM, FlashAttention e DeepSpeed
    • Mantém configuração otimizada com base no hardware e metadados consistentes

Problemas que pretende resolver

• Dificuldade na instalação de bibliotecas relacionadas a GPU, como PyTorch, CUDA, FlashAttention e DeepSpeed
• Desperdício de recursos causado por builds repetidos do mesmo pacote dentro da equipe
• Erros de build causados por atualizações do setuptools
• Inconveniência no processo de autenticação em registros internos

Estratégia de integração entre servidor e cliente

• Resolve diretamente esses problemas com a integração vertical entre uv (cliente) e pyx (servidor)
• É possível usar apenas uv sem pyx, ou apenas pyx sem uv, mas a melhor experiência vem ao usar os dois juntos
• A integração profunda com ferramentas open source torna possível uma experiência de desenvolvimento antes inviável

Modelo de negócios

• As ferramentas da Astral, como uv, Ruff e ty, permanecerão gratuitas para sempre, open source e sob licença permissiva
• Em vez disso, a empresa oferecerá serviços de hospedagem pagos como o pyx para atender à demanda por infraestrutura de “próximo nível”

Estado atual e planos futuros

• Atualmente está em operação com parceiros iniciais como Ramp, Intercom e fal
• Até o GA (disponibilidade geral), manterá um ciclo rápido de feedback por meio de open build
• A empresa convida equipes interessadas e fãs a entrarem em contato

[roxie]

Fui lendo pensando em como essa empresa ganha dinheiro, e pelo visto eles planejam oferecer o pyx como um serviço pago.

[ndrgrd]

Dizer que "All python packaging challenges are solved" é até engraçado.
Não é que foi resolvido; só empurraram tudo para funcionar de qualquer jeito, não foi? kkk

Python é uma linguagem principal usada no mundo todo, mas é fato que o ecossistema está bagunçado demais.
Nos comentários do Hacker News, o pessoal se preocupa com o fato de uma "empresa" entrar em cena, mas não percebe que a situação ficou assim justamente porque ninguém ligou para isso até uma empresa tomar a frente.

[aqqnucs]

Só para constar: citando algo que alguém disse nos comentários do Hacker News

[GN⁺]

Comentários no Hacker News

• Talvez seja mais útil compartilhar este post do blog https://astral.sh/blog/introducing-pyx

  • Apesar de este link trazer uma explicação mais clara, ainda não entendo bem qual problema eles estão tentando resolver nem de que forma concreta a solução funciona

• Acho que todos os problemas de empacotamento em Python já foram resolvidos. A lição aqui é que não existe uma única solução perfeita para todo problema. Aumentar a integração com empresas financiadas por VC ou depender da infraestrutura delas sempre é um grande risco para a comunidade FOSS

  • Comecei porque me disseram para usar pip. Mas era lento e dava problema com frequência. Então migrei para virtualenv, mas isso só resolveu parte do problema. Depois usei conda, que às vezes funcionava bem, mas bagunçou meu perfil do shell e frequentemente acabava com versões de pacotes conflitantes. Depois me recomendaram pipenv, que no começo parecia bom, mas o desenvolvimento foi abandonado e, depois da troca de mantenedores, passou a quebrar com frequência nas versões mais recentes. Aí me recomendaram poetry, mas era lento demais para usar. Então voltei para pip com venv embutido, mas reencontrei os mesmos problemas de antes, com ainda menos funcionalidades. Depois fui para uv, que pelo menos funcionava de verdade. Só que as dependências de que eu preciso têm builds e empacotamento diferentes por sistema operacional e por GPU, então meus colegas nem conseguem instalar esse projeto nos próprios laptops. Ainda bem que os problemas de empacotamento em Python já estão todos "resolvidos"

  • Dizer que "todos os problemas de empacotamento em Python já foram resolvidos" é, sinceramente, falar sem saber ou pura ignorância. O Python ainda não tem um jeito confiável de lidar com dependências nativas em diferentes plataformas. pip e setuptools não deveriam ser o estágio final desse ecossistema

  • Concordo com a preocupação, mas depois de usar uv economizei um tempo absurdo, então vou continuar usando até que os problemas do capital de risco estraguem tudo de vez. Quando isso acontecer, espero que a comunidade consiga convergir para uma direção só

  • Passei as últimas 3 horas brigando com Python e Debian e minha raiva contra o ecossistema Python só aumentou. Isso está longe de estar resolvido. No Debian, basicamente só recomendam usar venv, mas pacotes instalados em venv muitas vezes não são encontrados por ferramentas do tipo cmake. Também existem pacotes apt-get, e algumas ferramentas só encontram esses, enquanto outras não. Os nomes dos pacotes também não são consistentes. Meu console recomendou pipx, mas a experiência é parecida. E ainda restam vestígios antigos da disputa entre Python 2 e 3, então buscas por pacotes falham com frequência por causa da presença ou ausência do número da versão. Mesmo sem saber o que é c++headerparser, acabei convencido de que o certo é tirar Python da árvore de build e deixá-lo enterrado na história

  • Você é novo aqui? Recomendo tomar um pouco deste Kool Aid. Não precisa se preocupar com o logo "MongoDB" gravado no copo. Isso é coisa antiga

• Já me machuquei muitas vezes confiando em produtos open source. Já ouvi esse tipo de promessa incontáveis vezes. Em algum momento há uma aquisição, e anos de documentação, issues e PRs são limpos quase sem aviso. Aí a nova empresa lança algum produto comercial, mas sem funcionalidades essenciais que eu usava

  • Mesmo entendendo essa preocupação, quero destacar que o pyx é um produto estrategicamente separado das ferramentas já existentes da Astral. No anúncio oficial, eles dizem: "pyx é a concretização da estratégia da Astral, e as ferramentas da Astral continuarão gratuitas, open source e sob licenças muito permissivas para sempre". Nosso objetivo é reduzir essa preocupação criando um produto comercial sustentável à parte, em vez de monetizar as ferramentas open source

  • É uma preocupação totalmente compreensível. Dito isso, acho a reputação e o histórico da Astral realmente impressionantes. Fiquei surpreso ao ver uma reação tão cautelosa no HN. Trabalho com desenvolvimento em Python há mais de 10 anos, e sempre fico animado quando a Astral lança alguma coisa

  • Se fosse uma funcionalidade realmente valiosa, acho que teria sido incorporada ao pip

• Concordo muito com a observação de que é difícil instalar PyTorch, CUDA ou coisas como FlashAttention e DeepSpeed. No Windows (e no WSL), também existe o problema de alguns pacotes exigirem compiladores de versões muito antigas do Visual Studio, então você precisa ir atrás dos caminhos de download manualmente. Estou esperando uma experiência de desenvolvimento melhor

  • Na verdade, como o WSL é praticamente Linux, acho que a versão do compilador do Visual Studio importa pouco. Todos os binários do WSL são compilados com toolchains de Linux. No Windows, a libc também é muito estável desde o Win10. Binários compilados com VC++ 2015 ou superior mantêm compatibilidade de C-ABI entre si. As exceções são quando alguma linguagem ou recurso específico não é suportado por compiladores antigos, ou quando se tenta passar objetos C++ diretamente entre ABIs. Esses casos são raros

  • Passei por algo parecido e foi isso que me fez largar Ruby de vez, apesar do Rails. Eu via vídeos de Ruby e parecia que todo mundo se divertia desenvolvendo, o que dava inveja, mas no meu ambiente eu só conseguia configurar tudo usando uma droplet da DigitalOcean, e às vezes tudo quebrava em erros de compilação do Rails. Lá por 2012 eu queria entrar na onda do Rails, mas o processo de configuração/instalação sempre parecia um pesadelo. Aí fui para Python, que no começo funcionava bem, mas hoje, se envolve AI ou CUDA, o inferno de instalação é tão grande que às vezes parece melhor simplesmente seguir o script de shell de outra pessoa

  • Acho que, em fluxos de trabalho centrados em GPU, o empacotamento Python precisa ir nessa direção. Há duas coisas especialmente empolgantes. Primeiro, índices validados por compatibilidade para cada acelerador (por exemplo, CUDA/ROCm/CPU), para acabar com a discussão da matriz torch/cu*. Segundo, permitir que o cliente consulte metadados para paralelizar a instalação. Se o pyx conseguir reduzir esse “loop de tentativa e erro com pip” em ambientes de ML, além de oferecer builds direcionados ao hardware e hashes previsíveis, isso vai economizar um tempo enorme na montagem de ambientes. Também é positivo para construir confiança manter a ferramenta em open source e ganhar dinheiro com o serviço hospedado. Fico curioso se o pyx também vai oferecer verificações de supply chain, como grafo de dependências, dependências reversas (o que quebra se X→Y?), SBOM e comprovações de assinatura

  • Houve uma época em que se esperava que sistemas operacionais já trouxessem um compilador embutido

  • Antigamente, esse foi exatamente o motivo decisivo para eu usar anaconda

• Fizeram a piada de que "em breve existirão 14 padrões concorrentes de empacotamento Python". Na verdade, 14 é piada; já existem bem mais do que isso há muito tempo

  • O empacotamento em Python realmente tem muitos padrões, mas acho que a maioria dos que surgiram na última década não compete entre si. Na verdade, é mais o resultado de um acúmulo gradual de funcionalidades consideradas úteis. Isso acontece porque a padronização do empacotamento em Python segue um processo saudável, baseado em consenso, e não autoritário. Se fosse autoritário, acho que Python não teria alcançado o sucesso que tem hoje (para constar, já propus pelo menos 5 PEPs)

• Acho que o empacotamento em Python é a parte do Python que mais foge do Zen do Python

• Em setembro do ano passado, Charlie revelou no Mastodon que estava pensando nesse modelo de negócios https://hachyderm.io/@charliermarsh/113103564055291456

• Fico curioso sobre o que significa concretamente um registro com awareness de GPU. Isso quer dizer que o uv verificaria as especificações da minha GPU e buscaria automaticamente no Pyx o conjunto certo de pacotes para ela? Se isso for um registro privado e pago para clientes corporativos, uma empresa também poderia disponibilizar esse registro ao público como uma instância externa? Em outras palavras, se eu fosse um fornecedor, poderia operar um registro Pyx pago para meus pacotes e oferecê-lo como ponto de entrada para meus clientes?

  • O uv já suporta uma forma básica dessa ideia. Por exemplo, se você rodar uv pip install --torch-backend=auto torch, ele instala automaticamente, a partir do índice do PyTorch, a versão do PyTorch adequada à sua GPU. O pyx é uma expansão desse modelo. Em vez de ser só para PyTorch, ele teria índices curados para cada acelerador de hardware, e nesses índices haveria artefatos buildados para diferentes pacotes, versões, versões de Python, versões de PyTorch etc., todos com metadados consistentes. Em outras palavras, com pyx você conseguiria obter com facilidade builds mais adequados em termos de compatibilidade e desempenho, e o cliente uv também conseguiria encontrar automaticamente o índice pyx apropriado (essa parte é implementada por padrão, use você pyx ou não, mas com pyx fica muito mais poderosa). Além disso, a possibilidade de um fornecedor operar diretamente um registro no estilo pyx para seus próprios pacotes e oferecê-lo como entrada para clientes ainda não é oficialmente suportada, mas, se houver interesse concreto, vale entrar em contato para discutir

• Eu já disse isso algumas semanas atrás: em algum momento a Astral vai aplicar uma estratégia de monetização. Meu palpite é que não será em torno do Uv, mas sim de algo como um PyPI privado e protegido https://news.ycombinator.com/item?id=44712558

  • Não entendo muito bem o ponto desse comentário. Na verdade, o próprio Charlie Marsh explicou isso diretamente em setembro do ano passado: algo como um registro privado de pacotes para empresas poderia ser um exemplo estratégico (mesmo que não fosse necessariamente isso no fim), usado para deixar concreta a ideia da estratégia. A Astral tem sido muito transparente sobre seu modelo de negócios https://hachyderm.io/@charliermarsh/113103605702842937

  • “Monetização” pode soar negativo, mas eles realmente vêm criando ferramentas excelentes, então empresas que querem que eles resolvam ainda mais problemas certamente vão pagar por isso

  • Ainda não adotei o uv e estou observando quais serão os próximos passos. Recentemente também precisei reavaliar o uso de ferramentas da Anaconda por causa de mudanças de licença, e com o Qt foi a mesma coisa. Só de pensar em topar com mais um problema de licença já dá desânimo