Uv - herramienta ultrarrápida de empaquetado de Python implementada en Rust

• uv es un instalador y resolvedor de paquetes de Python ultrarrápido escrito en Rust, diseñado para reemplazar los flujos de trabajo de pip y pip-tools
• uv es un hito en el camino hacia un "Cargo para Python": un administrador integral de proyectos y paquetes de Python que sea rápido, confiable y fácil de usar
• Planean hacerse cargo del mantenimiento de Rye, la herramienta de empaquetado de Python desarrollada experimentalmente por Armin Ronacher, y expandir uv como su proyecto sucesor unificado

Enfoque obsesivo en el rendimiento

• uv es 8-10 veces más rápido que pip y pip-tools sin caché, y con caché es 80-115 veces más rápido.
• Usa una caché global de módulos para no volver a descargar ni compilar dependencias, y aprovecha Copy-on-Write y enlaces duros en sistemas de archivos compatibles para minimizar el uso de espacio en disco.

Optimizado para la adopción

• La versión inicial de uv es compatible con las API de pip y pip-tools, por lo que puede usarse en proyectos existentes sin cambios de configuración.
• uv se distribuye como un único binario estático y puede reemplazar pip, pip-tools y virtualenv.
• Puede instalarse por separado del propio Python, sin necesidad de gestionar instalaciones de pip según la versión de Python.

"Cargo para Python": uv y Rye

• uv es un hito intermedio hacia un administrador unificado de paquetes y proyectos de Python que sea rápido, confiable y fácil de usar.
• El objetivo de uv es ser un único binario que incluya no solo pip, pip-tools y virtualenv, sino también pipx, tox, poetry, pyenv, ruff y más.

API compatible

• En lugar de pip install, se puede usar uv pip install para instalar dependencias de Python desde la línea de comandos, archivos de requisitos o pyproject.toml.
• En lugar de pip-compile, se puede usar uv pip compile para generar un requirements.txt bloqueado.
• En lugar de pip-sync, se puede usar uv pip sync para sincronizar un requirements.txt bloqueado con el entorno virtual.

Hoja de ruta

• Después de este lanzamiento, planean priorizar el soporte a usuarios y enfocarse en mejorar la compatibilidad, el rendimiento y la estabilidad.
• Más adelante, el objetivo es expandir uv hasta convertirlo en un administrador completo de proyectos y paquetes de Python.

Agradecimientos

• Expresan su agradecimiento a todas las personas que contribuyeron directa o indirectamente al desarrollo de uv.
• En particular, agradecen a Jacob Finkelman y Matthieu Pizenberg, cuyo resolvedor base de versiones de PubGrub se usa en uv.

Opinión de GN⁺

• uv es una herramienta innovadora que ofrece a los desarrolladores de Python un rendimiento muy superior al de las herramientas tradicionales como pip, lo que puede reducir significativamente el tiempo de configuración de proyectos.
• Al estar escrita en Rust, refleja una nueva tendencia dentro del ecosistema de Python que prioriza el rendimiento y la estabilidad, y se espera que mejore mucho la experiencia de desarrollo.
• El desarrollo de uv apunta a la integración de herramientas de empaquetado y gestión de proyectos de Python, lo que permitiría a los desarrolladores trabajar de forma más eficiente y consistente.

[kyunghoon]

La velocidad es realmente impresionante;;

[ajh508]

Ojalá se amplíe y pueda reemplazar a conda.

[GN⁺]

Opiniones en Hacker News

• Dudas sobre un pip-and-more respaldado por capital de riesgo

  • Cuesta entender cómo un pip-and-more financiado por venture capital va a generar ingresos cuando se descomponga la impresora de dinero gratis.

• Pregunta sobre la falta de soporte de uv para generar lockfiles independientes de la plataforma

  • Sobre el hecho de que uv, a diferencia de Poetry o PDM, no genera un lockfile independiente de la plataforma, se considera que este enfoque depende de archivos de requirements y que no encaja con el objetivo de ser el "Cargo de Python".

• Evaluación positiva del soporte de uv para estrategias alternativas de resolución de dependencias

  • Aunque uv sigue por defecto la estrategia estándar de resolución de dependencias de Python, que prefiere las versiones compatibles más recientes de los paquetes, también ofrece la opción --resolution=lowest para probar con las versiones compatibles más bajas.
  • Es excelente que uv también permita generar una resolución para una versión de Python distinta de la instalada actualmente mediante el parámetro --python-version.

• Dudas sobre la complejidad del sistema de paquetes de Python

  • Se cuestiona cómo se llegó a una historia de packaging tan compleja cuando entre los valores del intérprete de Python está el principio de que "debería haber una forma obvia de hacerlo".

• Un punto interesante sobre el uso de pubgrub-rs por parte de uv

  • Se valora como algo curioso que uv use pubgrub-rs, una implementación en Rust del algoritmo de resolución de versiones pubgrub, escrito originalmente para el lenguaje Dart, y que resulte divertido ver esa cadena de inspiración entre lenguajes.

• Mención de una predicción sobre el rumbo del equipo de Astral

  • Se menciona que hace 11 días se había predicho que el equipo de Astral ampliaría las capacidades de ruff para que pudiera hacer todo lo que necesita un desarrollador de Python.

• Experiencia personal con la velocidad de pip

  • Se comenta que pip normalmente funciona rápido, pero se vuelve lento cuando tiene que descargar muchos datos o compilar bibliotecas nativas. En cambio, conda es muy lento, incluso en máquinas potentes.

• Postura escéptica ante un nuevo administrador de paquetes de Python

  • Apareció otro administrador de paquetes para Python, pero si realmente puede reemplazar a pip, entonces sería posible cambiarse a él por la mejora de velocidad, igual que se hizo con ruff. Hace falta una solución permanente para la gestión de paquetes en Python.

• Curiosidad sobre la decisión de uv de generar archivos requirements.txt específicos por plataforma

  • Se pregunta por qué uv decidió generar archivos requirements.txt específicos por plataforma, en lugar de producir archivos poetry.lock y pdm.lock independientes de la plataforma.

• Felicitaciones y reacción positiva al trabajo del equipo de Astral

  • Aunque se expresa preocupación por otro intento externo de "arreglar" el packaging de Python, también se celebra ver que se prioriza la compatibilidad. Se valora positivamente el esfuerzo del equipo de Astral por enfatizar la compatibilidad con herramientas y estándares existentes.

• Pregunta sobre los problemas de compilación de paquetes de pip

  • Se pregunta cómo planean hacer menos propensa a errores y más amigable para el usuario la compilación que algunos paquetes de pip requieren al depender de toolchains completos como gcc, g++, gtk o Qt.