Rye: una experiencia de Python sin complicaciones

• Rye es una herramienta de gestión de proyectos y paquetes que buscaba manejar en un solo lugar la instalación de Python, proyectos con pyproject.toml, dependencias, virtualenv e instalación de herramientas globales
• Actualmente, su desarrollo está discontinuado, y se recomienda usar uv, el proyecto sucesor creado por los mismos mantenedores
• Los usuarios actuales pueden migrar consultando la uv migration guide; Rye sigue disponible, pero no hay planes de más actualizaciones
• La interrupción de actualizaciones también incluye actualizaciones de seguridad, por lo que en proyectos nuevos o entornos con mantenimiento a largo plazo conviene considerar la transición a uv
• La experiencia integrada de Python a la que apuntaba Rye abarcaba proyectos complejos e incluso monorepos, pero el foco de mantenimiento se trasladó a uv

---

Estado actual de Rye

• Desarrollo discontinuado y recomendación de uv

  • Se recomienda a todos los usuarios usar uv
  • uv es el proyecto sucesor creado por los mismos mantenedores
  • uv se mantiene activamente y se usa mucho más que Rye
  • Los usuarios actuales de Rye pueden consultar la uv migration guide
  • Rye puede seguir usándose, pero no hay planes de actualizaciones adicionales
  • Tampoco hay actualizaciones de seguridad planificadas

Funciones que ofrecía Rye

• Rye era una solución de gestión de proyectos y paquetes para Python
• Fue creado con el objetivo de ser una herramienta integral para usuarios de Python
• Dentro de una experiencia unificada, cubría las siguientes tareas
  • Gestión de la instalación de Python
  • Gestión de proyectos basada en pyproject.toml
  • Gestión de dependencias
  • Gestión de virtualenv
  • Instalación de herramientas globales
• Fue diseñado para manejar proyectos complejos y monorepos
• El video introductorio está disponible en Watch an introduction

[lum7671]

Ya llevo un tiempo, pero después de usar varias cosas,
estoy usando Introduction - PDM.

Parece que también tendré que probar Rye.

[GN⁺]

Opiniones de Hacker News

• Una parte importante del desarrollo central de packaging ahora se está haciendo en uv, y como Rye usa uv internamente, cuando uv mejora, Rye también mejora
  Por ejemplo, recientemente se agregó a uv la resolución universal de dependencias, lo que permite crear un requirements.txt bloqueado con un único resultado de resolución que funciona en todas las plataformas y sistemas operativos, no solo en el sistema que se está ejecutando en ese momento; la versión más reciente de Rye también lo soporta
  https://github.com/astral-sh/uv
  Estoy desarrollando Rye y uv, así que si tienen preguntas puedo responderlas

  • Me da curiosidad si la resolución universal de dependencias de Rye/UV funciona correctamente también con PyTorch, o si sufre los mismos problemas que Poetry
    https://github.com/python-poetry/poetry/issues/6409
    https://news.ycombinator.com/item?id=39257501
  • Me gustaría saber si hay trabajo o planes que se puedan seguir para archivos de bloqueo multiplataforma
    Una de las razones por las que mi equipo duda en migrar es esta. Como hacemos trabajo de ML, tomando como ejemplo un proyecto basado en PyTorch, el estado deseado sería tener todas las dependencias en pyproject.toml y poder generar desde una Mac AArch64 o una workstation Windows AMD64 archivos de bloqueo para estas configuraciones de plataforma: Mac con PyTorch MPS por defecto, Windows con PyTorch CUDA, Linux AArch64 con PyTorch CPU, Linux AMD64 con PyTorch CPU, Linux AMD64 con PyTorch CUDA
    Gracias por crear Ruff; estamos muy satisfechos tanto con el linting como con el formateo
  • Gran trabajo. Antes, a veces tenía que configurar entornos de trabajo de proyectos en una computadora nueva, y pyenv+venv+pip siempre era doloroso; ahora me pasé a Rye
    Ahora basta con instalar Rye, traer el proyecto desde GitHub y escribir rye sync
  • Si están a cargo tanto de uv como de rye, me pregunto por qué mantienen los dos al mismo tiempo. Para evitar la confusión causada por la fragmentación y la carga de elegir, me parece que sería mejor cerrar rye ahora
  • Muchas empresas que valoran builds predecibles y de buen rendimiento se están pasando, y en ese proceso a menudo se necesita generación de SBOM para incorporarlo en herramientas como guac
    https://guac.sh/
    https://pypi.org/project/sbom4python/ https://github.com/CycloneDX/cyclonedx-python
    Gracias a la función agregada recientemente para desanclar dependencias, durante el desarrollo se puede fomentar que se mantenga la compatibilidad y, para la reproducibilidad, generar un requirements.txt exacto y explícito, lo que hace que la gestión de vulnerabilidades y la etapa de SBOM sean mucho más fáciles que con herramientas como Poetry
    Por razones similares estoy usando https://hatch.pypa.io/latest/why/, y también me gusta que combine bien con uv

• Lo que me generaba rechazo de Rye era que recomienda con mucha fuerza usar builds de Python no estándar
  En la página de filosofía (https://rye.astral.sh/philosophy/) se explica que los builds de CPython de python.org son completamente inadecuados, que según la plataforma solo hay instaladores .msi o solo tarballs, y que las distintas distribuciones de Python están muy fragmentadas y causan todo tipo de problemas en el subecosistema. Por eso este proyecto usa los builds standalone de indygreg, y dice que espera que algún día aparezcan builds de Python bien mantenidos y confiables que reemplacen el caos actual
  La información sobre esos builds de indygreg está en https://gregoryszorc.com/docs/python-build-standalone/main/, y también es posible elegir otro Python: https://rye.astral.sh/guide/toolchains/
  Sin embargo, casi nunca me he topado con los problemas que mencionan. Los builds oficiales de Python descargados de python.org funcionaron, el Python común instalado con el gestor de paquetes de la distribución funcionó, y el Python incluido en las imágenes oficiales de contenedores Docker también funcionó
  Es probable que esos builds especiales también funcionen bien, pero la no estandarización me hace dudar. Incluso tienen una lista de particularidades de comportamiento, y no entiendo por qué agregar particularidades a algo que no tiene problemas. Que la filosofía de Rye sea tan proactiva en usar esos builds también le resta atractivo frente a alternativas que usan por defecto el Python que ya existe en el sistema operativo

  • Probablemente se refieran a situaciones como esta: trabajas en una empresa que usa algo como un CentOS viejo, el gestor de paquetes del sistema no ofrece nada más nuevo que Python 3.6, y los binarios oficiales de python.org al ejecutarse muestran un error indescifrable sobre la versión de glibc
    Para compilar Python desde el código fuente necesitas nuevas dependencias del sistema, tarda mucho, y al final aparece otro error aún menos claro sobre archivos de encabezado faltantes. Al buscar ese error aparece un flag de ./configure que evita un problema que GCC upstream corrigió en 2017, y de todos modos termina funcionando
    Si nunca te encontraste con estos tres errores ni con un entorno de build manylinux, evitaste por completo un mundo de dolor. Lo mismo aplica al scripting de instalación en Windows o a partes de esa página como “limitaciones de instrucciones de CPU disponibles”
  • En builds, packaging y distribución de Python hay dos extremos. Uno es el camino real, y el otro es un pasillo con mil cuchillas. Si no entiendes la propuesta de un Python portable, es porque tuviste suerte y significa que seguiste en el camino real

• Descarga regularmente el código fuente de Python, lo compila con optimizaciones estándar de producción y lo instala en /use/local/python${version}; desde que salió Python 3.7 en 2018, funciona de forma muy consistente.
  En mi experiencia, estos comandos son tan estables y consistentes que podrían automatizarse. Me pregunto cuál es el punto que le preocupa al autor o cuál es la queja de fondo.

  • Decir que “las compilaciones de CPython de python.org son totalmente inadecuadas” quizá se refiere a que no hay binarios para macOS/Windows en los lanzamientos de seguridad de versiones antiguas de Python.
    Por ejemplo, no se puede descargar el instalador de Python 3.10.14; el último instalador para Windows es Python 3.10.11, del 5 de abril de 2023.
  • De acuerdo. Lo correcto sería apoyar a la PSF; sostener un nuevo “método correcto” es una postura rara.

• Me gusta Rye. Hace exactamente lo que promete, vuelve realmente agradable todo el proceso de venv/versiones de Python/empaquetado, y para alguien acostumbrado a las formas oficiales de usar Python, como pyproject.toml, se siente casi transparente.
  Además, hace que Python se sienta como Cargo, y Cargo también es una herramienta agradable de usar.

  • Si, como yo, ignoraste las herramientas tipo Poetry y te quedaste con pip-tools, uv, que Rye usa internamente, puede reemplazarlo directamente.
    Personalmente, creo que pip-tools tenía un diseño mucho mejor que Poetry o Pipenv. Era ortogonal tanto a pip como a virtualenv, porque ambos ya forman parte desde hace mucho del flujo de Python. Rye puede verse como una muestra de que gana un enfoque iterativo y conforme al estándar.
    Además de la mejora de velocidad gracias a Rust, me gusta que dé valores predeterminados adecuados sobre dónde poner los entornos virtuales (.venv) y cómo instalar varias versiones de Python. Parece algo pequeño, pero después de que los wheels resolvieran los problemas de instalación de numpy, esos valores predeterminados razonables y pip-tools integrado eran básicamente lo único que faltaba. En ese sentido, también me pregunto cuál era la razón de ser de Anaconda después de la aparición de los wheels binarios.
  • Empecé con Python oyendo que había una sola forma de hacer todo, pero la experiencia de instalación y gestión de entornos era un desastre.
    Me alegra que por fin esté mejorando.
  • Si “hace que Python se sienta como Cargo”, ya me convenció. Estaba pensando en probar pixi porque Poetry se pasó todo el día y aun así no pudo resolver las dependencias.
    Parece que hay más gestores de paquetes de Python que apps de chat de Google.
  • Me pregunto qué significa que “lo vuelve realmente agradable”. ¿Es demasiado difícil de resumir? En Anaconda o Poetry no encontré mucho que se sintiera como una decisión especialmente destacable desde el punto de vista de la experiencia de usuario.
    Y en cuanto a curaduría, la propuesta de confiar en una organización pequeña más que en organizaciones más grandes y antiguas no parece fácil de vender. Es decir, me pregunto qué es exactamente lo que promete. Lo que puedo leer es más o menos “un buen gestor de paquetes es bueno, rápido y bueno”, así que me gustaría ver una página de comparación o de filosofía.

• El cinismo de HN a veces sorprende.
  Me gusta Rye. Después de usar gestores de paquetes de otros lenguajes, como Cargo o Hex, siempre lamenté que Python no tuviera un sistema parecido, y Rye me quitó completamente esa sed. Desde mi posición de no querer instalar varias herramientas para gestionar venv, versiones de Python y dependencias de proyectos, me encanta que Rye se encargue de todo.

  • Me pregunto si has probado conda. ¿Cómo se compara Rye con conda?
    Todavía no tengo claro Rye, pero conda también puede gestionar bien venv, versiones de Python y dependencias de proyectos.
  • De acuerdo. Rye me está funcionando bien. Quería un Cargo para Python, y hasta ahora, desde mi punto de vista, Rye lo ha logrado.

• Encontrarse con un nuevo gestor de dependencias de Python se parece a descubrir por casualidad un nuevo framework de JavaScript.

  • Mi filosofía es simple. Si tiene que ser un programa distribuible, simplemente uso Go; si no necesita cosas como ports, uso Docker; y si el equipo de IT o alguien te entrega una computadora con el sistema operativo y la versión de Python que todos usan en la organización ya instalados, entonces usas venv.
    Si tienes que lidiar con ports, o distribuir el programa, o la biblioteca depende de C o de componentes del sistema operativo, conviene más empezar un trabajo de consultoría en el que, después de cobrar, no tengas que mantener la base de código ni hacerte responsable.
  • Exacto. Docker ya resolvió hace unos 10 años el problema de distribuir y ejecutar programas Python.
    Hoy también se puede ejecutar CUDA y PyTorch en Docker. En hilos como este, cuando alguien dice “simplemente usa Docker”, la respuesta habitual suele ser “no quiero aprender Docker”, pero incluso sin ninguna experiencia previa con Docker, levantar un contenedor de Python toma 10 minutos.
  • Sí. Pero, a diferencia de cosas como Poetry, esta sí es realmente buena.
  • Es realmente grave. Como usuario, frustra que después de tantos años todavía no haya un estándar.

• pixi(https://pixi.sh/latest/) es bueno. Permite fijar la versión de Python e instalar paquetes desde conda y PyPI, y está escrito en Rust.

  • Se ve interesante, pero se siente difícil invertir seriamente en otro ecosistema más. Me incomoda el enfoque de pedir que lo descargues con curl y lo pases por pipe a bash, y luego que hagas eval sobre la salida de comandos arbitrarios.
  • Gracias por el enlace. Me pregunto si es más rápido que conda.
  • pixi es excelente. Para quienes usan conda, pixi puede servir como reemplazo de conda con entornos vinculados al directorio del proyecto/Git, parecido a devbox/devenv/flox.
    El trasfondo es un poco complejo. La empresa Anaconda tenía conda, escrito en Python, y el ecosistema open source conda-forge es un canal de conda con bots de compilación en CI. Más tarde, bajo el mismo paraguas de conda-forge, apareció mamba, escrito en C++, como reemplazo de conda, y es un reemplazo directo real al punto de que alias conda=mamba debería funcionar. Hoy conda también usa libmamba como solver para ganar velocidad.
    Después, el autor de mamba lo separó en pixi y lo reescribió en Rust, cambiando la filosofía sobre la ubicación de los entornos y la forma de activarlos, pero sigue siendo totalmente compatible con entornos conda.

conda siempre admitió instalar paquetes de PyPI mediante pip en casos como cuando no están en los canales de conda, y pixi admite paquetes de PyPI mediante uv. Por eso pixi es rápido. Según el post del blog, también hay otras optimizaciones que lo hacen mucho más rápido incluso que mamba
Si usas paquetes que no son Python puro, lo adecuado es la familia conda. La elección del gestor de paquetes (conda/mamba/pixi) es secundaria
El problema de PyPI es la falta de un rol de guardián. A eso se suma la falta de una forma estándar de empaquetar paquetes que no son Python puro, lo que hace que el entorno tenga fugas o se vuelva irreproducible, especialmente si se distribuye solo el código fuente y se hacen cosas raras como bootstrapping del entorno desde setup.py, incluyendo hasta el compilador
Del lado de conda, el canal conda-forge hace un control de calidad bastante bueno. Revisa restricciones, licencias, problemas como que falten archivos de licencia en las distribuciones de PyPI, aislamiento del entorno, etc. Claro que no es perfecto, porque los mantenedores pueden usar un bot oficial que fusiona automáticamente cambios de PyPI con restricciones de versión incorrectas
El problema que ninguna herramienta resuelve hoy está centrado en PyPI. Hay que lidiar con paquetes que no están en conda, y en la práctica también estás obligado a publicar primero los releases de paquetes en PyPI
Incluso cuando instalas mediante conda paquetes que solo están en PyPI, algunas de sus dependencias pueden existir en conda. Que yo sepa, no hay ningún gestor de paquetes que use paquetes de conda para satisfacer dependencias de paquetes de PyPI. Puedes agregar manualmente paquetes de conda para cubrir dependencias, pero corres el riesgo de no aplicar las restricciones de versión correctas
Incluso al escribir paquetes Python open source, aunque la configuración dependa solo de canales de conda, en la mayoría de los casos tienes que publicar primero en PyPI, o conviene hacerlo. Esto se debe a que los releases en el canal conda-forge, en la práctica, requieren que exista en PyPI. Por eso, incluso para gente como yo, Rye todavía puede ser útil y vale la pena mirarlo

• Vale la pena saber que la gente de uv (https://astral.sh/blog/uv) tomó la posta de este proyecto de Armin
• En la página de introducción dice: “Rye is still a very experimental tool, but this guide is here to help you get started.”
  Este proyecto me genera mucha expectativa, pero planeo esperar hasta que esté en una etapa más madura. Me gusta todo lo demás que ha sacado el equipo de Astral, así que mis expectativas son altas
• Usamos rye para desarrollar la biblioteca openai-python, y nos ha ido muy bien
• Rye se ve bien y también disfruté bastante usar Poetry, pero realmente llegué a respetar la calidad de las herramientas básicas de Go
  Cada vez que empiezo un proyecto en Python siento que tengo que volver a aprender cuál es el estado actual de la gestión de dependencias/entornos virtuales