Control de entornos Conda: de hardlinks a manipular el cache

¿Cómo controla Conda sus entornos?

Conda no «revisa» activamente los entornos cuando los llamás. No hay un daemon vigilando ni un escaneo dinámico; todo es bastante más frío y determinista. Cuando creás un entorno, el sistema mantiene un catálogo central de paquetes descargados en el famoso pkgs/. Ahí están los tarballs extraídos, listos para usar con binarios, libs y metadata.

Al crear un env, Conda intenta no copiar paquetes si puede evitarlo. Para cada archivo del paquete, si el filesystem lo permite, se usa un hardlink. Si no (por otro disco o permisos), se recurre a una copia física o, en casos puntuales, un symlink.

Conda decide archivo por archivo. Los paquetes ya vienen con un layout exacto y conocido gracias a su metadata info/files. Sin embargo, los archivos «especiales» como ejecutables con shebang o scripts .bat no pueden ser hardlinkeados tal cual; ahí entra la lógica de conda-build para reescribir paths absolutos y ajustar referencias al prefijo del env.

Activar un entorno solo cambia variables como PATH o CONDA_PREFIX. Si borrás archivos a mano, Conda no se da cuenta hasta que algo falla. La integridad se basa en la confianza ciega y el cache pkgs/.

Clonar vs copiar manualmente

Copiar un entorno a mano parece equivalente, pero es donde Conda se pone protectora. Cuando usás conda create --clone, la herramienta lee la metadata del entorno original y reconstruye el entorno desde el cache pkgs/. Hardlinkea lo que puede y copia lo que necesita ser reescrito.

Si copiás el directorio a mano, los scripts pueden apuntar al Python viejo, o binarios con RPATHs rotos. El peor detalle es que copiar rompe la separación semántica entre «cache de paquetes» y «entorno», dejando a Conda confundida sobre qué es qué.

La conclusión es clara: conda --clone produce un clon lógico y físicamente correcto, mientras que copiar la carpeta genera un clon visual, frágil e inestable.

Fusionar directorios pkgs: experimentos peligrosos

A veces surge la idea de fusionar directorios para ahorrar tiempo. ¿Qué pasa si copias los directorios pkgs/ de una instalación vieja encima del directorio de una nueva?

En la práctica, esto suele funcionar porque Conda trata pkgs/ como un cache compartido. El archivo urls.txt, que contiene las URLs originales de los paquetes, es solo un registro histórico; no importa si lo fusionás o lo borras.

El verdadero riesgo está en el directorio cache/. Los archivos .json y .solv ahí son caches del solver que dependen de la versión de Conda y los canales configurados. No son portables entre instalaciones.

Mi recomendación es clara: copiar solo los paquetes extraídos, excluir el directorio cache/, y dejar que la nueva instalación regenere sus archivos automáticamente. Es una operación razonablemente segura si sabés qué ignorar.