Gentoo pide no usar uv-build como backend de Python

¿Por qué Gentoo pide no usar uv-build como backend de Python?

Un backend que agrega entre 1,2 MiB y 1,5 MiB a cada build está detrás de un problema que ya afectó a otra docena de paquetes en Gentoo: perdieron keywords, la marca de soporte por arquitectura de esa distribución. Ese backend es uv-build, la herramienta de Astral para empaquetar proyectos de Python, y un desarrollador que publica en el blog de Gentoo pide a la comunidad que deje de usarla.

Para un founder, el punto no es el purismo de una distribución de Linux: es que el costo de esa decisión no lo paga quien la toma, sino los contribuidores, los empaquetadores y los usuarios que compilan desde el código fuente.

El autor aclara algo importante: no está criticando a uv. Escribe que las herramientas de Astral son buenas y que su equipo responde rápido a los reportes. Su objeción es puntual al backend, y su argumento es de costo-beneficio: no sostiene que sea malo, sostiene que sus beneficios no superan sus desventajas.

Conviene fijar el vocabulario, porque de eso depende entender el debate. El build backend es la pieza que convierte tu código fuente en un wheel o un sdist. Desde PEP 517, es una pieza intercambiable: el mismo proyecto puede empaquetarse con flit-core, con hatchling o con uv-build. Esa intercambiabilidad es, además, uno de los argumentos del post.

El costo real: 1,5 MiB para empaquetar código Python puro

El primer problema es el peso. Según el post, en la versión 0.13.0 los wheels de uv-build ocupan entre 1,2 MiB y 1,5 MiB según la plataforma, frente a los 45 KiB del wheel de flit-core. Está escrito en Rust, y el autor concede que Rust tiene ventajas; lo que discute es que ninguna de ellas importe en un backend que empaqueta código Python puro.

El segundo es la frecuencia. El autor contó 12 releases de uv-build en los 30 días previos a la publicación de su entrada. En una distribución basada en código fuente como Gentoo, cada una de esas versiones se compila en la máquina del usuario. Su cálculo es directo: por cada 100 milisegundos que el backend le ahorra a alguien al instalar un paquete, los usuarios de Gentoo pasan horas recompilando versiones nuevas de uv-build una y otra vez.

La portabilidad, el problema que el autor considera más grave

Python funciona en casi cualquier plataforma donde consigas un compilador de C. Con Rust, la lista de plataformas soportadas crece despacio y, aun teniendo un compilador funcional, uv puede no funcionar.

El post enumera casos concretos: rustix::fs y su cadena de dependencias dejan fuera a SPARC sin razón aparente. En plataformas de 32 bits, el ejecutable resultante es tan grande que la cadena de herramientas de compilación se queda sin espacio de direcciones, y el ebuild de Gentoo para uv ya carga dos parches para poder compilarlo ahí. Añadir y mantener una plataforma nueva, concluye, es un trabajo a tiempo completo.

¿Qué ventajas ofrece uv-build y por qué no alcanzan?

El autor reconoce dos razones para usarlo y desarma las dos.

• Consistencia con uv en el resto del proyecto. No aplica: el backend es una pieza independiente, y PEP 517 existe justo para que cualquier backend funcione con cualquier frontend. flit-core y hatchling funcionan sin problemas junto a uv.
• Performance. La diferencia real ronda los 100 milisegundos en una acción que se ejecuta pocas veces, y puede quedar neutralizada por el tiempo de descargar un wheel de 1,5 MiB.

Después está el detalle de quién toca el backend: desarrolladores del proyecto, contribuidores, flujos de CI/CD, empaquetadores de distribuciones y usuarios de source distributions. Quien instala un paquete desde PyPI usa wheels y nunca ejecuta el backend. Y de todos esos grupos, el de usuarios de sdists es el más grande y el más castigado, justamente el que no recibe ningún beneficio de performance.

¿Usar uv-build puede costarte parte de tu audiencia?

Aquí la discusión deja de ser un tema de purismo y se vuelve relevante para cualquiera que publique una librería de Python.

Un backend pesado no lo pagas tú: lo paga cada persona que intenta empaquetar tu proyecto, desde el maintainer de una distribución hasta el usuario que compila desde el sdist en una máquina vieja o en una arquitectura poco común. Perder una keyword en Gentoo significa que en esa arquitectura tu paquete simplemente no está disponible.

El contexto macro suma. En marzo de 2026, SiliconANGLE reportó que OpenAI anunció planes para adquirir Astral, la empresa detrás de uv, sin revelar los términos del acuerdo. Según ese reporte, las herramientas de Astral están escritas en Rust, acumulan una base instalada de varios millones de desarrolladores y la compañía afirma que son entre 10 y 100 veces más rápidas que las alternativas. OpenAI las integraría con su asistente Codex, el equipo de Astral se sumaría a la compañía y el código abierto seguiría manteniéndose; además, Astral trabaja en pyx, un registro de paquetes de Python en la nube. El mismo artículo recuerda que Anthropic había adquirido Bun, un proyecto con un gestor de paquetes de características similares a las de uv, cuatro meses antes.

Un análisis de RepoForge.io sobre el estado del packaging de Python en 2026 llama a este fenómeno la Rustificación del tooling y señala un riesgo de bus factor: si uv se rompe, la cantidad de personas capaces de depurar ese código en Rust es mucho menor que la que puede hacerlo sobre herramientas escritas en Python. Es la misma preocupación que plantea el post de Gentoo, aplicada a toda la cadena.

¿Qué significa esto para tu startup?

Si tu empresa solo consume Python, el post no cambia tu operación. Si publicas una librería, una CLI o un paquete que otros instalan, cambia tres cosas.

Tu backend es parte de tu superficie de dependencias. Elegir uv-build en un paquete Python puro agrega una dependencia binaria de más de un megabyte a cada persona que lo construya. Es una decisión de producto, no un detalle de configuración: define en qué máquinas tu software se puede construir.

Puedes separar el frontend del backend. PEP 517 está pensado para eso. Puedes seguir usando uv para resolver dependencias, instalar y correr tu CI, y empaquetar con flit-core o hatchling. No pierdes velocidad en el trabajo diario y reduces el costo para todos los demás.

El mantenimiento downstream es un canal de distribución. Si tu meta es que tu librería llegue a la mayor cantidad de entornos posible, un backend que se compila en segundos es parte del producto.

Tres movimientos concretos para esta semana:

• Revisa la sección [build-system] de tu pyproject.toml. Si tu paquete es Python puro y usas uv-build, pregúntate qué ganas a cambio de 1,5 MiB y de atarte a una cadena de compilación en Rust.
• Instala tu propio paquete desde el sdist en un entorno limpio y en la plataforma más vieja que puedas conseguir. Ahí aparecen los problemas que tus usuarios de wheels nunca ven.
• Documenta qué plataformas soportas y por qué elegiste ese backend. Un README con esa decisión explícita ahorra reportes de bugs y fricción con los empaquetadores de distribuciones.

Conclusión

El debate no es uv sí o uv no. Es dónde conviene poner una herramienta compilada y ultraveloz. Como frontend, uv cambió el estándar de velocidad del ecosistema y eso es un aporte real. Como backend para paquetes Python puros, el costo lo absorben terceros que nunca eligieron esa dependencia.

La pregunta que deja el post es menos técnica de lo que parece: si mañana tu paquete tiene que compilarse en una arquitectura poco común, en una máquina de 32 bits o en el servidor de un empaquetador de una distribución que no conoces, ¿alguien puede hacerlo sin tu ayuda?

Fuentes

• A plea not to use uv-build (fuente original)
• OpenAI acquires open-source Python tooling startup Astral
• The State of Python Packaging in 2026