PYX: el siguiente paso del empaquetado en Python

 (astral.sh)
18 puntos por GN⁺ 2025-08-14 | 4 comentarios | Compartir por WhatsApp
  • pyx es un registro de paquetes nativo de Python creado por el equipo de desarrollo de uv, que mejora la velocidad de instalación desde PyPI, PyTorch y fuentes privadas hasta 10 veces
  • Va más allá del alcance de los registros de paquetes tradicionales y ofrece funciones de velocidad, seguridad y reconocimiento de GPU, con soporte tanto para paquetes internos como para fuentes públicas como PyPI y PyTorch
  • Proporciona URLs de índice dedicadas que permiten filtrar según criterios como popularidad del paquete, fecha de creación y presencia de vulnerabilidades, reforzando la seguridad y el cumplimiento
  • Gracias al soporte de estándares modernos especializados para Python y a la integración directa con uv, permite autenticación y uso sin configuración
  • Resuelve problemas clave de entornos empresariales como compilaciones duplicadas dentro del equipo, la dificultad de instalación de PyTorch y CUDA, compilaciones rotas e incomodidades de autenticación mediante una integración servidor-cliente
  • Con su función de reconocimiento de GPU, ofrece versiones precompiladas de PyTorch, vLLM, FlashAttention y DeepSpeed adaptadas al hardware, con metadatos consistentes y configuración óptima
  • Ofrece un rendimiento muy superior frente a otros registros privados gracias a artefactos optimizados y a la API de metadatos nativa de uv

La visión y el contexto de Astral

  • Astral es una empresa que crea herramientas de desarrollo de alto rendimiento para el ecosistema de Python, y es conocida por Ruff (linter y formateador) y uv (gestor de paquetes)
  • El motivo de su fundación fue la percepción de que, aunque Python es el lenguaje de programación más popular del mundo, no ha recibido suficiente apoyo en el aspecto de tooling
  • Actualmente, la cadena de herramientas de Astral supera las 100 millones de instalaciones mensuales, y uv procesa más de 500 millones de solicitudes al día, en un crecimiento explosivo
  • Su objetivo es convertir a Python en el ecosistema de programación más productivo, y para lograrlo busca construir una nube de Python más allá de las herramientas cliente

Introducción a pyx

  • pyx es un registro de paquetes nativo de Python diseñado como backend optimizado de uv
    • Permite alojar paquetes internos
    • También puede actuar como frontend acelerado y configurable para fuentes públicas como PyPI y el índice de PyTorch
  • Características principales
    • Velocidad de instalación rápida: optimización de instalación y compilación de paquetes
      • Aprovecha artefactos optimizados y la API de metadatos nativa de uv al instalar paquetes desde PyPI, PyTorch y fuentes privadas internas
      • Ofrece velocidades de hasta 10 veces más rápidas frente a otros registros privados
    • Mayor seguridad y cumplimiento: minimiza riesgos mediante la comprensión de dependencias y de la cadena de suministro
      • Permite crear URLs de índice dedicadas para filtrar paquetes
      • Controla el acceso a paquetes según criterios como popularidad, antigüedad de publicación y estado de vulnerabilidades
      • Garantiza compilaciones reproducibles del lado del servidor
    • Soporte de estándares modernos
      • Compatible con los estándares y flujos de trabajo de empaquetado más recientes, especializados para Python
      • Se integra directamente con uv para permitir autenticación y uso fluidos sin configuración adicional
    • Distribución de paquetes con reconocimiento de GPU: simplifica la compilación y distribución relacionadas con CUDA y PyTorch
      • Ofrece precompilados personalizados de bibliotecas de GPU como PyTorch, vLLM, FlashAttention y DeepSpeed
      • Mantiene una configuración óptima basada en el hardware y metadatos consistentes

Problemas que busca resolver

  • La dificultad de instalar bibliotecas relacionadas con GPU como PyTorch, CUDA, FlashAttention y DeepSpeed
  • El desperdicio de recursos por compilaciones repetidas del mismo paquete dentro de un equipo
  • Errores de compilación provocados por actualizaciones de setuptools
  • La incomodidad del proceso de autenticación en registros internos

Estrategia de integración servidor-cliente

  • Resuelve directamente estos problemas mediante la integración vertical de uv (cliente) y pyx (servidor)
  • Se puede usar uv sin pyx, o pyx sin uv, pero la mejor experiencia se obtiene al usarlos juntos
  • La integración profunda con herramientas open source permite crear experiencias de desarrollo que antes no eran posibles

Modelo de negocio

  • Las herramientas de Astral como uv, Ruff y ty seguirán siendo gratuitas, open source y con licencia permisiva para siempre
  • En cambio, ofrecerá servicios de hosting de pago como pyx para cubrir la demanda de infraestructura de “siguiente nivel”

Estado actual y planes futuros

  • Actualmente ya opera con socios iniciales como Ramp, Intercom y fal
  • Mantendrá un ciclo de retroalimentación rápido mediante una build abierta hasta el GA (disponibilidad general)
  • Invita a equipos interesados y seguidores a ponerse en contacto

Lecturas relacionadas

4 comentarios

 
roxie 2025-08-15

Mientras leía, pensaba: «¿Cómo ganará dinero esta empresa?», pero parece que planean ofrecer pyx como un servicio de pago.
 
ndrgrd 2025-08-14

Decir All python packaging challenges are solved da risa, la verdad.
¿No será que no se resolvió, sino que solo lo acomodaron para que más o menos funcione? jajaja

Python es un lenguaje principal que se usa en todo el mundo, pero la verdad es que su entorno está demasiado desordenado.
En los comentarios de Hacker News se preocupan porque intervenga una “empresa”, pero no parecen pensar que la situación llegó a este punto precisamente porque nadie le prestó atención hasta que apareció una empresa.
 
aqqnucs 2025-08-14

Para su información: alguien citó lo que dijo otra persona en un comentario de Hacker News
 
GN⁺ 2025-08-14
Comentarios en Hacker News

  • Quizá sea más útil compartir esta entrada del blog: https://astral.sh/blog/introducing-pyx

    • Aunque este enlace explica las cosas con más claridad, todavía no me queda bien claro qué problema intentan resolver ni cómo funciona exactamente su solución

  • Creo que todos los problemas del empaquetado de Python ya están resueltos. La lección aquí es que no existe una sola solución perfecta para todos los problemas. Aumentar la vinculación con empresas financiadas por VC o depender de su infraestructura siempre es un gran riesgo para la comunidad FOSS

    • A mí me dijeron que usara pip y empecé con eso. Pero era lento y seguido daba problemas. Entonces me pasé a virtualenv, pero eso solo resolvía una parte del problema. Después usé conda; a veces funcionaba bien, pero me dejó hecho un desastre el perfil del shell y además seguido terminaba con versiones de paquetes enredadas. Luego me recomendaron pipenv; al principio estuvo bien, pero como el desarrollo quedó abandonado y cambió la gente a cargo, en las versiones recientes se rompe a menudo. Después otra vez me recomendaron poetry, pero era demasiado lento para usarlo. Así que volví a pip y al venv integrado, pero me topé otra vez con los problemas de antes y además tenía menos funciones. Entonces me cambié a uv, y ese sí fue el primero que más o menos funcionó bien. Pero las dependencias que necesito tienen compilación y empaquetado distintos según el sistema operativo y la GPU, así que mis colegas ni siquiera pueden instalar este proyecto en sus laptops. Qué alivio saber que el problema del empaquetado en Python ya está “resuelto”

    • Decir que “todos los problemas del empaquetado de Python ya están resueltos” es, francamente, hablar sin saber o desde la ignorancia. Python todavía no tiene una forma confiable de manejar dependencias nativas en plataformas diversas. pip y setuptools no deberían ser la última palabra de este ecosistema

    • Entiendo la preocupación, pero desde que uso uv me ha ahorrado una cantidad enorme de tiempo, así que lo seguiré usando hasta que los males del capital de riesgo lo arruinen por completo. Ojalá para entonces la comunidad logre alinearse en una sola dirección

    • Pasé las últimas 3 horas peleándome con Python y Debian, y me volvió la furia contra el ecosistema de Python. Esto no está resuelto para nada. En Debian solo te recomiendan usar venv, pero los paquetes instalados en un venv muchas veces no los encuentran herramientas tipo cmake. También hay paquetes de apt-get, y algunas herramientas solo encuentran esos mientras otras no. Encima los nombres de los paquetes no son consistentes. Mi consola me recomendó pipx, pero la experiencia de uso es parecida. Además, todavía quedan residuos viejísimos de Python 2 vs 3, así que por incluir o no el número de versión seguido falla la detección de paquetes. Aunque no sé qué sea c++headerparser, al final terminé convencido de que lo correcto es sacar Python del árbol de compilación y enterrarlo en la historia

    • ¿Eres nuevo por aquí? Te recomiendo probar este Kool Aid. No hace falta que te preocupes por el logo de “MongoDB” grabado en el vaso. Eso ya es viejo

  • He salido herido demasiadas veces por confiar en productos open source. Ya escuché estas promesas incontables veces. En algún momento los compran, limpian años de documentación, issues y PR casi sin aviso, y luego la nueva empresa saca algún producto comercial al que le faltan funciones clave que yo sí usaba

    • Aunque entiendo esa preocupación, quiero subrayar que pyx es un producto estratégicamente separado de las herramientas existentes de Astral. En el anuncio oficial incluso dicen: “pyx es la materialización de la estrategia de Astral, y las herramientas de Astral seguirán siendo gratuitas, open source y con licencias muy permisivas para siempre”. Nuestra meta es reducir esa preocupación creando un producto aparte, comercialmente sostenible, en lugar de monetizar las herramientas open source

    • Es una preocupación totalmente válida. Aun así, creo que la reputación y el historial de Astral son realmente impresionantes. Me sorprendió ver una reacción tan cautelosa en HN. Llevo más de 10 años desarrollando en Python, y cuando Astral hace algo, siempre me entusiasma

    • Si fuera una función realmente valiosa, creo que ya la habrían integrado en pip

  • Me identifico muchísimo con la crítica de que instalar cosas como PyTorch, CUDA, FlashAttention o DeepSpeed es difícil. En Windows (y también en WSL), algunos paquetes incluso exigen compiladores de versiones antiquísimas de Visual Studio, así que terminas buscando manualmente rutas de descarga absurdas. Sigo esperando una mejor experiencia de desarrollo

    • En realidad, como WSL es casi igual que Linux, no creo que la versión del compilador de Visual Studio importe demasiado. Todos los binarios de WSL se compilan con toolchains de Linux. Incluso en Windows, libc es muy estable desde Win10. Los binarios compilados con VC++ 2015 o superior mantienen compatibilidad de C-ABI entre sí. Solo en casos excepcionales hace falta un compilador viejo: cuando un compilador anterior no soporta cierto lenguaje o cierta función, o cuando intentas pasar objetos de C++ directamente entre ABIs. Esos casos son raros

    • Por este tipo de episodios terminé alejándome por completo de Ruby por culpa de Rails. Veía videos de Ruby y todos parecían desarrollar felices, y sí me daba envidia, pero en mi entorno para preparar el entorno de desarrollo tenía que usar un droplet de DigitalOcean, y además seguido se arruinaba todo con errores al compilar para Rails. Quise subirme al boom de Rails por ahí de 2012, pero el proceso de configuración e instalación siempre fue una pesadilla. Por eso me pasé a Python; al principio me fue bien, pero hoy, si hay AI o CUDA de por medio, siento que ya es mejor seguir el shell script de alguien más que entrar al infierno de instalación

    • Creo que en flujos de trabajo centrados en GPU el empaquetado de Python sí debería ir en esta dirección. Hay dos cosas que me entusiasman especialmente. Primero, que existan índices con compatibilidad validada por acelerador (por ejemplo, CUDA/ROCm/CPU por separado), para que desaparezca la discusión interminable de la matriz torch/cu*. Segundo, que el cliente pueda consultar metadatos para paralelizar la instalación. Si pyx logra reducir ese “bucle de prueba y error con pip” en entornos de ML, y además aporta compilaciones orientadas al hardware objetivo y hashes predecibles, se ahorraría muchísimo tiempo en preparar entornos. Además, mantener la herramienta como open source y ganar dinero con el servicio hospedado es un modelo positivo para generar confianza. Me pregunto si pyx también soportará verificaciones de cadena de suministro como grafo de dependencias, dependencias inversas (¿qué se rompe si X→Y?), SBOM o pruebas de firma

    • Hubo un tiempo en que era normal que un sistema operativo incluyera un compilador

    • La razón decisiva por la que antes usaba anaconda era justo este tipo de entorno

  • Hicieron el chiste de que “pronto habrá 14 estándares competidores para empaquetado en Python”. En realidad, lo de 14 era broma; hace rato que ya hay más que eso

    • En el empaquetado de Python sí hay muchísimos estándares, pero creo que la mayoría de los que surgieron en la última década no compiten entre sí. Más bien son el resultado de una acumulación gradual de funciones consideradas útiles. Eso ocurre porque la estandarización del empaquetado en Python ha sido un proceso sano, basado en consenso más que en autoritarismo. Si hubiera sido autoritario, no creo que Python hubiera tenido el éxito que tiene hoy (como referencia, he propuesto al menos 5 PEP)

  • Creo que el empaquetado en Python es la parte que más contradice el Zen de Python

  • En septiembre del año pasado, Charlie comentó en Mastodon que estaba pensando en este modelo de negocio: https://hachyderm.io/@charliermarsh/113103564055291456

  • Me da curiosidad qué significa exactamente un registro con conciencia de GPU. ¿Se supone que uv revisa las especificaciones de mi GPU y luego pyx me trae automáticamente el conjunto de paquetes adecuado? Si esto es un registro privado y de pago para clientes empresariales, ¿una empresa también podría ofrecer ese registro al exterior como una instancia pública? Es decir, si yo fuera un vendor, ¿podría operar un registro pyx de pago para mis paquetes y usarlo como punto de entrada para mis clientes?

    • uv ya soporta una versión básica de esta idea. Por ejemplo, si haces uv pip install --torch-backend=auto torch, instala automáticamente desde el índice de PyTorch la versión que corresponde a tu GPU. pyx es una extensión mucho más amplia de ese modelo. No solo para PyTorch, sino con índices cuidadosamente curados para cada acelerador de hardware, donde ya están preparados los artefactos compilados para distintos paquetes, versiones, versiones de Python, versiones de PyTorch, etc., junto con metadatos consistentes. O sea, con pyx puedes obtener fácilmente builds que encajan bien en compatibilidad y rendimiento, y el cliente uv también puede encontrar automáticamente el índice pyx adecuado (esa parte se implementa de base uses o no pyx, aunque con pyx es mucho más potente). Además, que un vendor opere directamente un registro tipo pyx adaptado a sus propios paquetes y lo use como entrada para sus clientes todavía no está soportado oficialmente, pero si hay interés concreto se puede platicar

  • Ya lo había dicho hace unas semanas: en algún momento Astral va a aplicar una estrategia de monetización. Mi apuesta es que no será con Uv, sino con algo como un PyPI privado y protegido https://news.ycombinator.com/item?id=44712558

    • No me queda muy claro cuál es el punto de ese comentario. De hecho, Charlie Marsh ya había explicado esto directamente en septiembre pasado: algo como un registro privado de paquetes para empresas podría ser un ejemplo estratégico (aunque no necesariamente tenga que ser exactamente eso; lo mencionó para ilustrar de forma concreta la estrategia). Astral ha sido muy transparente sobre su modelo de negocio https://hachyderm.io/@charliermarsh/113103605702842937

    • “Monetización” puede sonar negativo, pero han creado herramientas realmente excelentes, así que las empresas que quieran que resuelvan todavía más problemas estarán totalmente dispuestas a pagar

    • Todavía no adopto uv y estoy observando qué rumbo toma. Últimamente también tuve que reevaluar el uso de herramientas de Anaconda por cambios de licencia, y lo mismo con Qt. Solo pensar en enfrentar otro problema de licencias ya me pesa