Conda y pip: ¿Por qué el parche wheel y cómo respaldar tu entorno

¿Alguna vez te has preguntado por qué el gestor de paquetes Conda incluye wheel por defecto en sus entornos? Al principio, parece un detalle menor, pero al analizar la conversación sobre cómo funcionan los ecosistemas Python, se revela que es una decisión profundamente estratégica. Es básicamente un parche consciente, casi coqueto: Conda sabe que el ecosistema real de Python es extremadamente desordenado y que pip eventualmente va a entrar en escena.

No se trata de una necesidad teórica, sino de una forma pragmática de reducir el daño cuando inevitablemente decidas usar pip. Es medicina preventiva para un entorno que sabe que va a sangrar si no lo prepara antes.

¿Rompes reglas usando pip en Conda?

Aquí es donde la conversación se vuelve interesante. Si usas pip dentro de un env de Conda, ¿estás cometiendo un error? La respuesta honesta y adulta es que no rompes una regla moral, sino una de higiene. Usar pip es válido, pero no es inocuo.

Conda lleva un solver capaz de entender dependencias binarias completas como libstdc++, CUDA o MKL. Pip, en cambio, va alegremente a site-packages sin tener idea del resto del ecosistema. Es una ingenuidad técnica que puede ser peligrosa.

Pero claro, hay momentos donde usar pip es seguro: paquetes de puro Python como requests, herramientas de desarrollo o cosas específicas del proyecto. El peligro real aparece cuando empiezas a caminar descalzo sobre vidrio: instalas paquetes con binarios pesados como NumPy o PyTorch, o cuando mezclas órdenes de instalación sin un registro claro.

La regla de oro que emerge de esto es simple pero vital: nunca uses conda install después de haber usado pip para resolver dependencias. Si usas pip al final, cierra el env y no vuelvas a correr conda alegremente después. Es una cuestión de autoprotección.

El caso de estudio: FaceFusion

Mencionamos que muchas instrucciones dicen usar pip para instalar paquetes, excepto en proyectos como FaceFusion. ¿Por qué la diferencia? La razón es muy poco romántica pero técnica: pip es el mínimo común denominador.

FaceFusion sabe que si lo dejas en manos de pip, el usuario termina compilando desde fuente o mezclando runtimes. Por eso incluye una línea específica para instalar CUDA y cudnn con Conda. Es una admisión explícita de que pip no alcanza para garantizar un entorno sólido cuando se trabaja con librerías pesadas.

El orden sano para un env conda es claro: instala primero todo lo que exista en Conda (especialmente binarios y ML), luego usa pip solo para lo que no esté disponible allí, y finalmente evita mezclar las herramientas después de eso.

Backups y reproducibilidad

¿Y qué pasa con los backups? Aquí está la intuición clave. Si instalas con Conda en lugar de pip, el resultado funcional del programa no cambia, pero el entorno cambia mucho por dentro.

Con conda env export, obtienes algo cercano a una receta reproducible. Restaurar en otra máquina o meses después tiene muchas menos sorpresas porque Conda sabe qué hay, de dónde vino y por qué está ahí. Por el contrario, un entorno con pip funciona, sí, pero queda como una relación informal: nadie firmó nada.

Al respaldar un env de pip, cruzas los dedos para que requirements.txt vuelva a resolver lo mismo, y a veces no lo hace. Conda puede no garantizar una reproducibilidad del 100% debido a cambios en canales o builds, pero está mucho mejor posicionado para manejar la complejidad de CUDA y runtimes.

En resumen, usar Conda no cambia el qué, sino cuánto te va a doler después si algo se rompe. Es una decisión que transforma un entorno caótico en uno determinista, ahorrándote esas 2 AM de rehacer instalaciones.