Rye y uv: agosto es temporada de cosecha para el empaquetado de Python
(lucumr.pocoo.org)- Después de que la administración de Rye pasara a Astral en febrero de 2024, uv, su resolver e installer base, mejoró rápidamente y surgió como candidato para unificar las herramientas de empaquetado de Python
- La versión más reciente de uv ya incluye manipulación de
pyproject.toml, soporte de workspaces, referencias a paquetes locales, instalación de scripts y hasta gestión de instalación de Python, absorbiendo el terreno que antes cubría Rye - Con la inversión en AI y ML han aumentado los nuevos usuarios de Python, pero como hay demasiadas opciones de herramientas de empaquetado y la compatibilidad entre ellas no siempre coincide, la experiencia de desarrollo sigue sin ser consistente
- El ecosistema de empaquetado necesita una herramienta dominante que todos usen para que la inversión y la documentación se concentren en un solo stack, y Rye podría convertirse en la ruta de migración hacia un cambio centrado en uv
- La inversión de VC en Astral es un riesgo que la PSF y los proyectos core de Python deben considerar, pero aun en el peor escenario uv es evaluado como un código que puede bifurcarse y mantenerse
La tendencia de concentración de funciones de Rye en uv
- En febrero de 2024, la administración de Rye pasó a Astral, y en los meses siguientes Astral mejoró rápidamente las herramientas de empaquetado de Python
- Los usuarios de Rye pudieron notar que uv, el resolver e installer subyacente, se volvió mejor y más rápido
- La versión actual de uv empezó a ofrecer directamente funciones para las que antes hacía falta Rye
- manipulación de archivos
pyproject.toml - soporte de workspaces
- referencias a paquetes locales
- instalación de scripts
- gestión de instalación de Python
- manipulación de archivos
- Quienes hoy usan Rye necesitan revisar uv y dar feedback a Astral
Por qué las herramientas de empaquetado de Python deben converger
- La charla de EuroPython Prague se centra en la situación actual del empaquetado de Python y en las lecciones aprendidas al crear Rye
- El objetivo de una herramienta de empaquetado es convertirse en la herramienta dominante de ese espacio
- La mejor herramienta debería ser la que todos usan
- Porque es la herramienta con la que se topa quien recién empieza su recorrido en programación con Python
- En los últimos dos años, Python se volvió una plataforma muy atractiva y popular para nuevos desarrolladores gracias a la inversión y el interés en AI y ML
- Es importante que los nuevos usuarios recuerden a Python no como un lenguaje viejo con malas herramientas, sino como uno con una experiencia de desarrollo sobresaliente
- Sin embargo, hoy el empaquetado de Python tiene demasiadas opciones, la compatibilidad entre herramientas no es total y varias inconsistencias afectan la experiencia
- Algunos usuarios siguen una herramienta, chocan con un muro, terminan moviendo todo el stack a conda y luego vuelven otra vez
La posibilidad de que uv se convierta en la herramienta dominante
- Que una herramienta ocupe una posición dominante significa que la mayor parte de la inversión se concentra en un solo stack
- Lo deseable es que Rye y varias herramientas a su alrededor ya no necesiten existir de forma independiente una vez que se establezca una herramienta dominante
- Hoy uv es vista como la herramienta con más posibilidades de asumir ese rol
- Todavía no cubre todos los casos de uso
- Pero parece estar acercándose a ese punto con rapidez
- Este es el momento en que la comunidad debería empezar a agruparse alrededor de uv
- Eso no significa que esta herramienta vaya a ser la única para siempre
- Las herramientas pueden aparecer y desaparecer
- En el futuro podría surgir otra herramienta
El retiro de Rye y el cambio en la orientación para proyectos Python
- El lanzamiento final esperado de Rye retiraría sus funciones propias, migraría a los usuarios hacia uv y en gran medida funcionaría como una especie de alias de uv
- Retirar solo Rye no es suficiente
- Hoy en Python se usan varias soluciones de gestión de paquetes
- La comunidad debería orientar hacia un número menor de herramientas
- Rye y uv se construyeron sobre muchos años de evolución del ecosistema que está debajo
- la transición de
setup.pya eggs, y luego a wheels - el paso de no tener estándares de metadatos a contar con ellos
- el cambio de sistemas de build acoplados a sistemas de build desacoplados
- el trabajo que hizo posible redistribuir y descargar binarios de Python
- el ecosistema relacionado de crates de Rust y librerías de Python
- la transición de
- La comunidad debe prepararse para decir, en algún momento, que ciertas herramientas ya no se recomiendan
- Antes, la documentación para nuevos desarrolladores recomendaba
ez_setup.pyyeasy_install - Después se eliminó
ez_setup.pyde las guías y se reemplazó porpip - Algunos proyectos orientaron a usar
pip-tools,poetryyPDM - Hoy muchos proyectos incluso muestran al mismo tiempo cinco instrucciones de instalación debido a la variedad de herramientas
- Antes, la documentación para nuevos desarrolladores recomendaba
- Quienes mantienen proyectos importantes de Python deberían probar uv directamente y evaluar si pueden recomendar uv a sus usuarios
- El texto de Charlie de Astral sobre lo que uv puede hacer hoy muestra los avances actuales de uv
La inversión de VC en Astral y el riesgo para la comunidad
- El hecho de que Astral, que desarrolla uv, sea una empresa que recibió inversión de VC es un tema imposible de evitar
- Desde la perspectiva de la comunidad, que alguien inyecte mucho dinero puede crear nuevos desafíos
- La PSF y los proyectos core de Python deben tener esto en cuenta
- Al ver el código y el funcionamiento de uv, parece ser algo que incluso en el peor futuro podría bifurcarse y mantenerse
- Aunque Astral cerrara o hiciera algo muy cuestionable en términos de licencia, la comunidad podría seguir en una posición mejor que antes de que uv existiera
1 comentarios
Opiniones en Hacker News
La versión más reciente de uv también se comentó ayer: https://news.ycombinator.com/item?id=41302475
El artículo enlazado es la opinión que escribió el autor de Rye tras ver esa versión
Para quienes estén interesados en uv, al usar uv en lugar de pip, el proceso de lanzamiento de Home Assistant se aceleró muchísimo
El tiempo de lanzamiento pasó de unas 2,5 horas a unos 20 minutos, y hay más detalles en https://developers.home-assistant.io/blog/2024/04/03/build-i.... Como referencia, yo solo soy usuario de HA
Aunque uso Python de forma ligera, no sé qué diablos hacía para tardar tanto, y me parece absurdo
Sé que el empaquetado de Python tiene problemas, pero personalmente hasta ahora he llegado bastante lejos solo con plain pip
El mayor cambio fue pasar del virtualenv original al módulo venv integrado. Si tuviera que tomarme realmente en serio la gestión de dependencias, probablemente haría un monorepo al estilo FAANG y evitaría las molestias relacionadas con los gestores de paquetes
Administro un monorepo de Python en producción y la gestión de dependencias es un infierno. Estoy intentando aplicar algunas funciones nuevas de Poetry, pero el estado del ecosistema alrededor de los monorepos grandes es espantoso
El objetivo no es “para mí es suficiente”, sino contar con una herramienta estándar de paquetes y entornos virtuales que escale desde organizaciones con 2 desarrolladores Python hasta cientos o miles de personas. De lo contrario, el ecosistema se fragmenta, aumentan los bugs y la documentación difícil, y se vuelve complicado que el lenguaje siga avanzando de forma efectiva
Pero no hay forma de definir para qué versión de Python se creó un proyecto. Si creas un paquete, probablemente tengas que probarlo con varias versiones; y si no es un paquete distribuible instalable, sino un conjunto de código compartido por algunos desarrolladores, para tareas como ejecutar modelos de machine learning, desplegar funciones en la nube o generar reportes, normalmente querrás apuntar exactamente a una sola versión de Python
También me pregunto si el enfoque de monorepo significa copiar numpy y pandas dentro del repositorio
Al principio esperaba que una herramienta nueva resolviera el problema del “empaquetado” en Python, pero al leer más vi que se trataba más de gestión de paquetes que de empaquetar aplicaciones Python que yo haya creado
Personalmente no he tenido grandes problemas con la gestión de paquetes en Python; aunque al ecosistema le faltan cosas, salvo detalles como la ausencia de namespaces, pip en general funciona bien
Lo realmente molesto es no poder envolver fácilmente una aplicación Python en un ejecutable y desplegarla en algún lado. En producción veo a menudo que se hace git clone y se crea un virtualenv, lo que exige al servidor de destino más conectividad de la necesaria y a veces deja dependencias de desarrollo en el sistema operativo. Desde el punto de vista de seguridad es una muy mala idea, así que hasta que se resuelva ese problema voy a preferir otros lenguajes para trabajos que requieran despliegue a usuarios finales o en producción
Para eso, la aplicación debe llegar al usuario, encontrar Python allí, y todo el proceso debe ser transparente para el usuario. Una de las razones por las que al crear Rye, y lo mismo con uv, se intentó dar soporte a la instalación de Python de una forma que no rompiera el sistema fue precisamente esa
Una forma más avanzada sería automatizar todo el proceso, incluso uv. Incluso hoy, si quisieras, podrías usar un instalador curl to bash para instalar uv/Rye y la app en una ubicación temporal dedicada a esa aplicación, sin romper nunca el sistema del usuario
Ojalá algún día este proceso sea completamente transparente, no requiera acceso a la red y también ofrezca cosas como .msi para Windows. Pero la premisa es que herramientas como uv deben poder ubicar arbitrariamente un Python precompilado y todas las dependencias necesarias en el lugar adecuado para la plataforma del usuario
El bonus final que uv podría ofrecer algún día sería un artefacto completamente empaquetado, y eso estaría muy bien. Incluso el paso anterior ya podría hacer que la experiencia de entregar herramientas de línea de comandos hechas en Python a los usuarios deje de ser horrible. Puedes usar uvx o, si quieres, ocultar por completo el propio uv
Por ejemplo, hay herramientas que crean instaladores por sistema operativo, y también han aparecido herramientas para desplegar en lugares particulares como Android, iOS o el navegador. Por supuesto, un paquete específico puede no funcionar en un destino específico, pero como existe una interfaz estándar, si el código puede ejecutarse en algún lugar, la herramienta para ese destino debería poder producir un resultado que funcione allí
Después del rug pull de npm financiado con capital de riesgo y su adquisición por Microsoft, y después de que OpenAI mostrara que incluso el estatus legal sin fines de lucro no es más que marketing sin fuerza para líderes enredados en la ruta del capital de riesgo, me da reticencia entregar a este tipo de organizaciones la infraestructura de lenguaje que está en la ruta crítica.
Las personas que contribuyen allí son excelentes, y a menudo sobresalientes, pero los intereses financieros a nivel organizacional están contaminados desde el inicio. Después de 1 a 4 años, lo que importa es la organización. Es como eso de “mueres como héroe o vives lo suficiente para convertirte en villano”.
Por eso, linters rápidos, verificación de tipos, escaneo de código y asistentes de PR están bien, y se pueden cambiar en cualquier momento. Pero no el flujo de instalación ni los repositorios de paquetes.
Es lamentable si pensamos en el estado de pip y conda, pero creo que esa es la realidad.
Creo que Microsoft es dueño de Python, solo que no lo muestra públicamente.
Hace unos años quise crear bindings de Python para kubectl, pero descubrí que, para que funcionaran en varias plataformas, CGo tenía que usar el mismo compilador que Python en todas las plataformas. Pero en Windows CGO usa MINGW y Python usa MSVC. En la lista de correo de desarrollo de Python que existía en ese entonces pregunté por qué un proyecto “open source” usaba un compilador propietario, y la respuesta fue que MSVC era una elección histórica y que ahora no se podía cambiar. La explicación fue que Microsoft le proporcionaba a la Python Foundation infraestructura gratuita para correr CI y builds, y también aportaba desarrolladores que trabajaban en el intérprete de Python. Es decir, empleados de Microsoft trabajan en el intérprete de Python cobrando dinero de Microsoft y reciben instrucciones de no quitar herramientas de Microsoft de la cadena de herramientas.
Cada año la situación empeoró. Como en proyectos similares, el éxito creó el terreno para que gente sin mucha capacidad tomara poder, y la Python Foundation y proyectos periféricos como PyPA empezaron a llenarse de personas que llegaron a esos puestos escribiendo páginas de códigos de conducta, no contribuyendo código útil. Las disputas interminables alrededor de ese código de conducta y del control de puestos terminaron haciendo que contribuyentes veteranos se fueran o fueran expulsados; recientemente incluso fue vetado Tim, el creador de Tim sort.
Microsoft sigue impulsando la agenda habitual que aplica en cada proyecto que toca: agregar montones de funciones inútiles para hacer publicidad, hacer que el proyecto se sacuda en todas direcciones y, en especial, que siga las modas al máximo. Por eso Python, aunque es un lenguaje con un sistema de tipos completamente distinto, intenta agregar tantos tipos estilo machine learning como sea posible; y aunque es un lenguaje que se usa en buena parte para enlazar dinámicamente bibliotecas nativas, está obsesionado con la precompilación y el JIT. En esencia, lo están convirtiendo en C# sin llaves.
Microsoft es lo bastante inteligente como para saber que, si anunciara públicamente que posee Python, mucha gente se alejaría de la tecnología, así que no lo promociona demasiado. Pero sigue haciendo que los desarrolladores dependan de sus herramientas, y algún día vendrá a recuperar esa inversión.
Pero hasta ahora lo único que han producido son miles de millones de posts de blog de contribuidores que, en esencia, dicen: “el sistema que creamos nos impide ser útiles y, de todos modos, no es culpa nuestra”.
Parecen tan metidos en sus sistemas internos y su política interna que ya ni saben por qué están ahí.
Así que si alguien realmente lo hace bien y se adueña del mercado como Astral, ese es exactamente el resultado que nosotros, como comunidad, merecemos.
[1]: Me refiero aquí a política interna. No a un berrinche raro de extrema derecha tipo “¡contrataciones DEI!”.
Estas herramientas todavía tienen el problema de la autoridad.
A diferencia de cargo, no están aprobadas por PyPA. Al mismo tiempo, PyPA no ha logrado ofrecer una solución integral durante años, y las herramientas de empaquetado y desarrollo de Python no han dejado de multiplicarse. Hace apenas 3 o 4 años parecía que poetry y pipenv resolvían problemas de empaquetado de Python que pip+virtualenv no podían resolver.
Ahora creo que PyPA debería subirse al barco de astral.sh, pero no sé si lo hará sin cierto nivel de control.
A mi parecer, en gran parte fue por relaciones personales, y en ese momento Pipenv era desastroso. Tenía buenas intenciones, pero en el trabajo había que esperar una hora para actualizar el lockfile incluso en repositorios con relativamente pocas dependencias ampliamente usadas. Simplemente no funcionaba.
En términos prácticos, agradezco mucho el difícil trabajo técnico que hace PyPA. Pero no me importa demasiado qué conjunto de herramientas recomienda hoy. Creo que es mejor usar lo que usa la comunidad y no preocuparse por las propuestas “oficiales”.
No está claro cuántas personas participan, ni qué tan relacionada está PyPA con el núcleo de Python o con la PSF.
Creo que la aprobación que realmente ayudaría sería la del propio proyecto central de Python. En un mundo ideal, el tutorial oficial de Python empezaría con “así se instala Python” y guiaría desde la instalación de uv, igual que la documentación oficial de Rust apunta a rustup y cargo.
Espero firmemente que la PSF construya algún tipo de relación con Astral para que algún día esa realidad sea posible.
Creo que en este contexto ya demostró por sí misma que en gran medida es irrelevante. Todo lo que toca parece pudrirse, así que, lamentablemente, preferiría que se mantuviera alejada de este problema. Me duele decirlo y va contra mi filosofía, pero es una evaluación que refleja el estado actual. Llevo 10 años trabajando full time con Python, y otros ecosistemas de empaquetado prácticamente le sacaron más de una vuelta a Python.
Ya ni me importan matices como “si es un problema de ejecución de PyPA o si el alcance de su rol está mal definido”. También estoy cansado de que me arrastren a esas discusiones.
Armin defiende que uv domine este ámbito, pero también reconoce que, al estar basado en inversión de capital de riesgo, podría haber un rug pull.
Como solución a ese posible problema dice que “es muy fácil hacerle un fork”, pero ¿un fork no genera, por naturaleza, más fragmentación? Justamente el problema que él quiere resolver.
Si una herramienta aspira a dominar el panorama del empaquetado en Python, creo que debería ser impulsada y controlada por la comunidad.
El nivel de fragmentación después de que una herramienta retirada con un rug pull haya logrado unificar primero podría ser mucho menor que antes de esa unificación.
¿Y esta comunidad imaginaria necesita varias décadas más para crear una gran herramienta dominante?
Esta mañana en la empresa estuve evaluando migrar nuestro software de Poetry a uv por la lentitud de Poetry.
Hasta ahora he leído bastante documentación, pero no he avanzado mucho en la práctica. Yo también hice antes la migración a Poetry, y aquella vez fue mucho más simple. Por lo que veo hasta ahora, Poetry intentó crear un gestor de paquetes simple que se comportara como otros gestores de paquetes, mientras que uv parece conservar bastante de la locura de los paquetes de Python.
Tampoco pasa que un cambio menor en Poetry rompa el formato de package.toml, ni que la resolución en múltiples índices tarde más por esos “sources” tontos que no funcionan con dependencias transitivas.
uv se siente básicamente como algo que encaja directamente en el flujo estándar de herramientas de Python.
No culparía a la gente si decide saltarse esta ronda y esperar a la edición 2026 de “Gestor de paquetes de Python: ¡esta vez sí lo resolvimos de verdad!”.
Aun así, yo sigo siendo un usuario satisfecho de Nix.
Me gusta mucho este encuadre.
Gracias al trabajo que mucha gente fue acumulando gradualmente durante mucho tiempo, ahora llegamos a un punto en el que unas pocas personas de una empresa pueden mejorar drásticamente la situación con un esfuerzo moderado.