El Caché de Pip: ¿Por qué Ocupa 95 GB y Cómo Gestionarlo

El Descubrimiento del Directorio uv

Hace poco, al revisar mis archivos, encontré un directorio llamado `uv` dentro de `AppDataLocal`. Mi primera reacción fue preguntarme qué programa usaba ese espacio. Tras investigar, confirmé que se trata de uv, el gestor moderno de paquetes y entornos Python desarrollado por Astral.

A diferencia de herramientas clásicas como pip, virtualenv o incluso poetry, uv intenta compartir más recursos entre proyectos mediante cachés centralizadas. Sin embargo, al mirar el tamaño total del sistema, me encontré con un número que no podía creer: tenía 95 GB acumulados en mi caché de pip.

¿Qué Hace Realmente el Caché de Pip?

Para empezar a limpiar o entender el problema, es fundamental saber qué hace este directorio. El caché de pip guarda los archivos descargados para las instalaciones, como los paquetes en formato .whl o distribuciones fuente.

Es importante aclarar una duda común: ¿borrar el caché significa que mis entornos cambiarán? La respuesta es no. El caché solo conserva archivos descargados; no afecta a las instalaciones activas ni rompe los entornos virtuales existentes. Lo único que ocurre al borrar esos 95 GB es que la próxima vez que pip instale algo, tendrá que volver a descargarlo desde cero.

El Problema de la Reproducibilidad: ¿Por qué el Caché Crece?

A medida que profundicé en el problema, noté una contradicción interesante. Si el caché no fija versiones, ¿por qué es tan grande? La respuesta radica en cómo funcionan las dependencias.

Si tu archivo requirements.txt contiene simplemente torch sin especificar una versión, cada vez que instales un entorno nuevo, pip puede decidir descargar la última versión disponible. Con el tiempo, el caché se llena de versiones antiguas y nuevas.

Esto contrasta con las mejores prácticas para proyectos complejos como ComfyUI o Wan2GP. Para garantizar que una instalación funcione hoy igual que ayer, es necesario usar archivos «lock» (como uv.lock) que congelan el árbol completo de dependencias directas e indirectas.

Los Custom Nodes de ComfyUI: Más Allá del Directorio

Llegamos a una parte crucial de la conversación: el software ComfyUI. Al principio pensé que los custom nodes simplemente copiaban archivos en un directorio compartido. Sin embargo, tras analizar cómo interactúan con el sistema, descubrí que es mucho más invasivo.

Muchos custom nodes no solo copian scripts; a menudo ejecutan pip install -r requirements.txt para instalar paquetes directamente en el entorno Python de ComfyUI. Además, algunos descargan modelos automáticamente o modifican archivos de configuración globales.

Por Qué No Centralizar los Custom Nodes

Dado que los custom nodes alteran las instalaciones, surgió la idea de centralizarlos en un solo directorio para todas mis copias de ComfyUI. Pero esta conclusión fue errónea. Al reconsiderar la arquitectura del software, es evidente que compartir el mismo directorio custom_nodes entre diferentes instalaciones es una mala práctica.

Cada instalación de ComfyUI tiene su propia versión y su propio entorno Python con librerías específicas. Un nodo diseñado para funcionar con una versión antigua de PyTorch podría fallar catastróficamente si se usa en un entorno que utiliza una versión más nueva.

La solución robusta es mantener las instalaciones separadas: modelos compartidos, pero custom nodes y entornos virtuales independientes. Aunque esto consuma un poco más de espacio en disco, la estabilidad y la capacidad de reproducir entornos funcionales son mucho más valiosas que ahorrar unos pocos gigabytes.