uv o pip: instalar ocho veces más rápido exige cambiar cómo bloqueas dependencias

En la prueba de Real Python, instalar JupyterLab en frío tardó 2,618 segundos con uv pip install y 21,409 segundos con python -m pip install: uv fue aproximadamente ocho veces más rápido en ese entorno. Si las instalaciones consumen tiempo en desarrollo o CI, uv merece una prueba; ese resultado procede de su interfaz compatible con pip y no exige adoptar de inmediato el gestor de proyectos de uv.

La decisión tiene dos alcances. Se puede sustituir el instalador y conservar requirements.txt, o migrar también la declaración y el bloqueo de dependencias a pyproject.toml y uv.lock. pip sigue siendo razonable si el flujo actual cumple los tiempos previstos, depende de opciones específicas o añadir uv a las imágenes y al CI cuesta más de lo que ahorra.

Qué mide la ventaja de velocidad

La comparación de JupyterLab usó entornos virtuales separados y vació las cachés antes de instalar. Mide una instalación inicial, no el tiempo total de construir una imagen, ejecutar pruebas o desplegar una aplicación. Tampoco fija una ventaja universal: el hardware, la red, los paquetes elegidos y el estado de la caché pueden cambiar el resultado.

Una instalación con caché responde a otra pregunta. Cuando las distribuciones ya están disponibles, disminuye el trabajo de descarga; cuando una dependencia debe compilarse, su preparación puede pesar más que el instalador. Para estimar el efecto en un repositorio, hay que comparar el mismo archivo de dependencias y la misma versión de Python en entornos vacíos y en el CI habitual. El tiempo que importa para decidir es el del trabajo completo, aunque conviene medir la instalación por separado para localizar el ahorro.

Requirements.txt o uv.lock: qué queda fijado

Cambiar a uv pip no obliga a cambiar de archivo. La guía de bloqueo de uv muestra que uv pip compile requirements.in -o requirements.txt genera un archivo con versiones fijadas y que uv pip sync requirements.txt ajusta el entorno a su contenido. uv pip install -r requirements.txt también instala desde ese archivo, pero puede conservar paquetes ajenos que ya estaban presentes. Si se busca una réplica del entorno, requirements.txt debe incluir además las dependencias transitivas necesarias para la sincronización.

En un proyecto gestionado por uv, pyproject.toml contiene las dependencias declaradas y uv.lock registra las versiones resueltas. El bloqueo puede contemplar distintas plataformas y versiones de Python en un mismo repositorio. Migrar significa acordar qué archivo se edita, cuál se incorpora al control de versiones y qué comando usan desarrollo, CI e imágenes. Mantener a la vez dos archivos de versiones modificados de forma independiente abre la puerta a instalaciones distintas.

pip también ofrece formas de fijar dependencias. La documentación de pip lock califica ese comando de experimental y limita la validez garantizada del bloqueo generado a la plataforma y versión de Python actuales. Un requirements.txt con versiones fijadas, generado por ejemplo con pip-tools y consumido de forma coherente, sigue siendo una opción para un flujo existente. La diferencia práctica es el formato y el alcance del bloqueo que deberá mantener cada proyecto.

Comandos para cada alcance de migración

La sustitución de comandos es más corta si requirements.txt continúa gobernando las versiones. El flujo de proyecto añade operaciones que modifican la declaración de dependencias y el bloqueo; cambiar solo el comando de instalación no realiza esa conversión.

• Instalar un paquete: python -m pip install paquete pasa a uv pip install paquete con los archivos actuales. En un proyecto gestionado por uv, uv add paquete incorpora la dependencia al proyecto y actualiza su resolución.
• Instalar desde un archivo: python -m pip install -r requirements.txt pasa a uv pip install -r requirements.txt. Para ajustar el entorno a un archivo completo de versiones fijadas, se usa uv pip sync requirements.txt.
• Crear el entorno: python -m venv .venv puede sustituirse por uv venv. En el flujo de proyecto, uv sync crea el entorno del repositorio si falta y lo sincroniza.
• Fijar versiones: si las dependencias directas están en requirements.in, uv pip compile requirements.in -o requirements.txt conserva ese esquema. Con pyproject.toml como declaración del proyecto, uv lock crea o actualiza uv.lock.
• Retirar una dependencia: python -m pip uninstall paquete tiene su equivalente puntual en uv pip uninstall paquete. uv remove paquete modifica la declaración del proyecto; la sincronización retira del entorno lo que deja de figurar en el bloqueo.

Los comandos de desinstalación puntual quitan el paquete solicitado, pero pueden dejar dependencias transitivas que ningún otro paquete necesita. La limpieza del entorno llega al sincronizar contra un conjunto completo de dependencias, tanto con uv pip sync como con el flujo de proyecto. Por eso sustituir pip install por uv pip install aporta una posible mejora de velocidad sin cambiar por sí solo la política de limpieza.

Qué cambia en CI y en las imágenes

Al adoptar uv.lock, el CI necesita disponer de uv, pyproject.toml y el archivo de bloqueo. La documentación de sincronización de uv indica que uv sync elimina por defecto los paquetes ausentes del bloqueo y que --locked falla si el archivo está desactualizado. Así, uv sync --locked permite detectar una declaración modificada sin actualizar el bloqueo durante el trabajo de CI.

Ese cambio también afecta a las imágenes que todavía instalan requirements.txt con pip. uv permite exportar ese formato desde uv.lock para una transición, pero el archivo exportado debe derivarse del bloqueo que gobierna el proyecto. En imágenes con capas de dependencias separadas del código, el orden de copia de pyproject.toml y uv.lock influye en la reutilización de la caché de construcción. Conviene contar ese tiempo junto al coste de incorporar uv a la imagen, porque el cronómetro de una instalación aislada no mide el proceso completo.

Cuándo conservar pip

La interfaz uv pip cubre usos habituales, aunque sus reglas no son idénticas a las de pip. La guía de compatibilidad de uv señala que no admite --user, no lee pip.conf ni PIP_INDEX_URL y puede elegir paquetes de forma distinta cuando hay varios índices. Una imagen que instala en el esquema de usuario o un CI configurado mediante esas opciones necesita ajustes antes de sustituir el comando. Las restricciones de versiones poco precisas también pueden producir una resolución válida pero diferente.

Conservar pip tiene sentido cuando esas integraciones son importantes y el tiempo de instalación ya es aceptable. Usar uv pip con requirements.txt permite evaluar la velocidad sin convertir la gestión del proyecto. Adoptar pyproject.toml, uv.lock y uv sync responde a una decisión más amplia: mantener una resolución compartida y sincronizar entornos de manera consistente, con el trabajo correspondiente de adaptar comandos, archivos e imágenes.

Lee también:

• El instalador parece auténtico, pero cambia de carga en cada descarga
• Firefox o Vivaldi: más controles no siempre bloquean más rastreadores
• Jalapeño promete hasta 1,9 veces más trabajo de IA por vatio