La función de formateo de código llega experimentalmente a uv

• La nueva versión de uv ofrece de forma experimental una función de formateo de código
• El comando uv format usa internamente el formateador de Ruff para dar un estilo consistente al código Python
• Ahora es posible ordenar y formatear código fácilmente solo con uv sin necesitar una herramienta aparte
• Los usuarios pueden ajustar en detalle el comportamiento del formateo mediante argumentos adicionales
• Como todavía es una función experimental, es posible que cambien la forma del comando y el manejo de errores

---

Resumen

La versión más reciente de uv (0.8.13) introduce uv format, un comando experimental que los desarrolladores de Python llevaban tiempo esperando. Con esta función, es posible organizar el estilo del código usando solo uv dentro del proyecto, sin tener que gestionar una herramienta de formateo adicional

¿Qué es uv format?

• El comando uv format ofrece formateo de código Python a través de la interfaz de uv
• Internamente, invoca el formateador de Ruff para organizar automáticamente el código de manera consistente

Nota para desarrolladores

Charlie Marsh (desarrollador de uv) explicó lo siguiente en Hacker News

Ruff y uv no se están fusionando; siguen siendo herramientas separadas.
El objetivo es simplemente mejorar la experiencia para que el usuario pueda usar el formateador sin percibirlo como una herramienta aparte.
Es similar a la relación entre cargo fmt y rustfmt en el ecosistema de Rust.

Cómo usarlo

• Debes usar uv 0.8.13 o una versión superior
• Si ejecutas el comando uv format en la raíz del proyecto, el efecto es el mismo que ejecutar ruff format
• La forma de ejecución sigue la interfaz de comandos de uv

Pasar argumentos adicionales

• Con la forma uv format -- [argumentos adicionales] puedes configurar opciones detalladas que se pasan a Ruff
• Así puedes aprovechar al mismo tiempo la comodidad de uv y la configuración fina de Ruff

Aviso sobre la etapa experimental

• Actualmente, esta función está en una etapa experimental, por lo que en el futuro podrían cambiar tanto la forma del comando como la manera en que se integra con la estructura del proyecto
• El manejo de errores y el formato de salida también seguirán mejorándose
• La función evolucionará incorporando los comentarios de los usuarios

Cierre

• Si necesitas un estilo de código simple y consistente en proyectos Python, vale la pena probar uv format
• Como se trata de una incorporación experimental, usarlo directamente y enviar comentarios puede contribuir al desarrollo futuro de uv

[GN⁺]

Comentarios en Hacker News

• Creo que sería mejor que ruff se fusionara con ty; uv debería concentrarse en la gestión de paquetes o proyectos y no meterse en la edición del estilo del código. Pienso que el único caso en que uv debería modificar archivos de código es al actualizar dependencias (PEP 723)
  • Quiero dejar claro que ruff y uv no se van a fusionar y seguirán siendo herramientas separadas; la idea es ofrecer una experiencia más simple para quienes no quieren preocuparse por el formateador. Es una configuración similar a Rust, donde cargo fmt ejecuta rustfmt internamente
  • Es básicamente imitar la forma en que existe cargo fmt en Rust
  • En esencia, el objetivo es convertir a uv en un gestor de paquetes de Python completo, y cada herramienta componente también puede usarse por separado si hace falta. Es decir, uv sería algo así como cargo para Python, y si solo necesitas un verificador de tipos rápido, usarías ty; si solo necesitas un formateador/linter, usarías ruff. En ese sentido, fusionar ruff y ty no parece tener mucho sentido
  • También me pregunto qué pasaría si algún día ty terminara integrándose en uv; como todo viene de astral.sh, quizá esa sea la visión, aunque ty todavía no parece estar listo
  • El siguiente paso lógico sería introducir algo como uv lint para que ejecute ty internamente. Idealmente, estaría bueno poder preparar un proyecto de Python (formatear, lint, probar, publicar) con un comando estándar o una serie de comandos; quizá esa sea la visión detrás de esto
• Me encanta usar uv, pero me preocupa un poco que se esté volviendo innecesariamente grande. Por ejemplo, muchos subcomandos soportan demasiadas flags peculiares, y algunas incluso producen casi el mismo resultado (uv run --no-project y uv run --active, por ejemplo). Más que agregar funciones nuevas porque sí, preferiría que se enfocaran en mejorar las herramientas y la documentación existentes
  • Hacer que un proyecto de Python sea estable, reproducible y portable es realmente difícil. En teoría, uv sync es muy útil porque solo construye conjuntos de paquetes que pueden reproducirse de nuevo, pero paquetes complejos como torch-tensorrt o flash-attn inevitablemente dependen del entorno. La comunidad de Python a menudo tiende a personalizar el problema con un "en mi máquina funciona", pero el costo de distribuir software de forma segura, repetible y confiable nunca desaparece; al final alguien termina pagándolo después, en un contexto más restringido. Intentar satisfacer todas esas distintas necesidades de usuarios y operación es realmente complicado
  • No entiendo muy bien por qué agregar subcomandos a uv se considera inflarlo demasiado. uv ya es una herramienta compleja y además está bien documentada. Si los comandos son así de intuitivos y autoexplicativos, me parece bastante natural sumarlos
  • Cuando se habla de uv, se siente un poco como decir que "el comando make tiene demasiados targets"
  • Me pregunto si estas opciones quedan integradas en el ejecutable principal o si funcionan como binarios separados, como en apt o cargo
• Me parece que esta actualización fue claramente una buena decisión. No entiendo por qué tanta gente se opone a algo mejor; claro, es cierto que "ya se puede hacer de una forma un poco más incómoda", pero justamente es "un poco más incómoda"
  • No me parece malo que uvx ruff format tenga una palabra más; más bien podría volverse confuso qué formateador se ejecuta realmente, si ruff se instala automáticamente o si, como hasta ahora, la herramienta se descarga y se guarda en caché
  • Coincido totalmente; incluso sería mejor si permitieran configurar el formateador desde pyproject
  • Mi mayor queja es que, por ahora, no parece haber soporte para otros formateadores. Si en mi proyecto uso black, entonces uv format no funciona
• Personalmente, tengo muchas expectativas con este cambio porque creo que hará muchísimo más fácil el formateo de código para mi equipo pequeño, cuyos miembros principales son actuarios. Como uv ya tuvo bastante impacto en la adopción y el onboarding de Python, cualquier forma de elevar la calidad del código con más facilidad siempre es bienvenida. Claro, también se puede usar solo ruff o configurar pre-commit, pero el modelo mental simple de uv <función> ayuda mucho al equipo. También estaría bueno que se pudiera integrar con otros formateadores, y si incluso soportara formateo de modelos SQL/dbt, no pediría nada más. Por ahora pienso probarlo y ver qué posibilidades abre
  • Si necesitas ese nivel de formateo múltiple, quizá sea mejor usar algo como un Makefile o un justfile; así podrías hacer just format y formatear Python/SQL/Bash/TypeScript de una sola vez
• Se siente un poco como exceso de funciones. Llevo más de un año usando uv cada vez más y reconozco sus ventajas, pero todavía no es mi primera opción, y no creo que este tipo de cambios haga que lo prefiera más
  • Me gustaría saber qué problema concreto le ves a este enfoque. Go, Rust y Elixir lo adoptan, y en esos ecosistemas hace mucho más fácil configurar y usar proyectos. La comunidad puede concentrarse en un conjunto común de herramientas y se ofrece un punto de entrada consistente tanto para principiantes como para expertos
  • Si es así, me da curiosidad saber qué herramienta prefieres más
• Algún día, probablemente las funciones de ruff terminen integradas en uv y ty. El linting podría quedar a cargo de ty, que entiende mejor la base de código, y el formateo encajaría bien en uv, cuyo objetivo principal es la gestión del proyecto
  • Como ty ya está en el mismo repositorio que ruff, la integración tampoco parece algo tan lejano
• Un gestor de paquetes es indispensable para instalar paquetes del entorno de ejecución, pero mezclarlo con herramientas solo de desarrollo se siente como una especie de "trampa atractiva pero peligrosa". Claro, Go y Rust también lo hacen, pero si lo piensas desde la base, no me parece una estructura tan buena
  • Puede sonar muy mal, pero como alguien que ha usado mucho cargo, ojalá hubiera más "malas ideas" de este tipo. Si uv llega a cumplir ese papel de cargo en Python, la experiencia de desarrollo en Python va a mejorar muchísimo. Después de más de 25 años usando Python y lidiando con muchas de sus carencias, me resulta muy satisfactorio que ahora se pueda resolver casi todo con uv sin tener que pensarlo demasiado
• El nuevo uv format es básicamente un atajo para uv run --with ruff ruff
• Me gusta mucho esta dirección; si dependiera de mí, lo llamaría uv fmt y también agregaría algo como uv vet al roadmap
• Ya hay muchas herramientas de formateo de código bien probadas, así que no siento ninguna necesidad de introducir esto. Solo se siente como más funcionalidad, así que por ahora no pienso incluirlo en ningún pipeline
  • uv format es básicamente un frontend de ruff format; no se está agregando un formateador nuevo
  • Ojalá más gente entendiera que no es más que un atajo para usar fácilmente ruff format, que ya usa mucha gente