La desinstalación de nodos ComfyUI: gestionando el infierno de las dependencias

Uno de los problemas más frustrantes al trabajar con ComfyUI es cómo se manejan las instalaciones. He estado pensando en hacerme un script de instalación básica, porque el último intento volvió a hacer un desastre con los tiempos de renderizado.

La raíz del problema suele ser la falta de limpieza. Cuando usas el manager para instalar nodos, ejecuta un `pip install -r requirements.txt`, pero al borrarlos, simplemente elimina las carpetas y deja las dependencias Python instaladas en el entorno. Esto provoca entornos inflados, versiones incompatibles y paquetes huérfanos que eventualmente rompen otros nodos silenciosamente.

La solución más sana es tratar esto como una infraestructura reproducible: un «core limpio» de ComfyUI, una lista explícita de nodos aprobados y snapshots de versiones. Al final del día, mucha gente avanzada termina usando entornos virtuales separados para diferentes cargas de trabajo, como `ComfyUI_stable` o `ComfyUI_experimental`, en lugar de intentar que una sola instalación soporte todo el ecosistema.

Por otro lado, me surgió la duda sobre si debería avanzar a PyTorch 2.12 o quedarme con la estabilidad del 2.10. Mi conclusión es que depende mucho de mi hardware y de lo que valore: rendimiento puro versus estabilidad absoluta. Para una instalación estándar, el costo de migrar a una versión tan reciente como 2.12 puede ser innecesario.

Para evitar este caos en el futuro, la mejor estrategia técnica es congelar commits concretos usando Git. En lugar de vivir siempre en `master`, puedo clonar versiones específicas o usar clones `shallow` para ahorrar tiempo y asegurar que mi stack sea predecible.

Finalmente, al migrar una instalación, es crucial mantener los directorios `models/`, `input/` y `output/` aparte del núcleo de la aplicación. Solo necesito versionar y respaldar el directorio `user/default` para preservar mis workflows y configuraciones personales sin tener que mover gigabytes de datos cada vez.