Ten en cuenta que en la informática un problema puede tener varias resoluciones, no obstante nosotros aquí te mostraremos lo más óptimo y mejor.
Solución:
No, PyPI no es el problema. En lugar de, falla porque YAML incluye restricciones de compilación específicas de la plataforma, pero está transfiriendo entre plataformas. Específicamente, examinar los números de compilación de los paquetes fallidos (p. ej., six=py36h0e22d5e_1
), puedo ver que corresponden a paquetes de la osx-64
plataforma, pero está tratando de instalar en una linux-64
plataforma, por lo tanto, las restricciones de compilación no se pueden resolver.
Omitir información de compilación
La solución más simple a esto es omitir la información de compilación de la exportación de definición de entorno.
conda env export -n py36 -f py36.yml --no-builds
Todavía puede haber problemas si algunos de los paquetes no están disponibles en linux-64
a través de Conda. Si este es el caso, es posible que deba buscar otros canales (o verificar PyPI), cambiar de versión o eliminar la dependencia por completo. Sin embargo, la mayoría de los paquetes parecen estándar.
No es tan importante, pero puede eliminarlo con seguridad cvxgrp
de tus canales. Ese canal solo sirve una versión desactualizada de cvxopt
y solo para osx-64
.
Solo especificaciones explícitas
Otra opción, aún más vagamente definida, es generar solo lo que Conda se refiere como especificaciones explícitas. Estos indican solo aquellos requisitos que han sido solicitados explícitamente por el usuario. Esto incluye paquetes, pero también captura cualquier restricción de versión, etc., que proporcionó el usuario en algún momento.
conda env export -n py36 -f py36.yml --from-history
La ventaja aquí es que se ignorarán las dependencias específicas de la plataforma.
De hecho, los entornos mantienen las especificaciones de compilación de la plataforma bajo el conda-installed (es decir, dependencies
) sección. De la muestra de OP:
- zlib=1.2.11=hf3cbc9b_2
, hf3cbc9b_2
es una etiqueta de versión específica de la plataforma. Tienes que quitar eso.
Si cambia de plataforma con mucha frecuencia (OSX <-> Linux, por ejemplo), lea la respuesta de @merv, eso es lo que debe hacer en su futuro env export
.
Por el momento, como yo, solo quiero que lo arreglen, puede hacerlo manualmente o ejecutar un sed
encima de eso:
sed 's/(.*[[:alnum:]])=[[:alnum:]][[:alnum:].-_]*/1/' environment.yml > env.yml
. Eso manejará la etiqueta específica de la plataforma sin tocar el pip
sección del archivo.
Entonces puedes intentarlo de nuevo con env.yml
:
conda env create -f env.yml
Tenga en cuenta que la plataforma específica paquetes puede ocurrir. Si después de eliminar las etiquetas de versión, Conda aún se queja, deberá limpiar manualmente los paquetes en consecuencia. Por ejemplo, traigo un
environment.yml
de Linux a Mac, donde los paqueteslibgcc-ng=9.1.0
,libstdcxx-ng=9.1.0
,libgfortran-ng=7.3.0
no están definidos; Los quité a mano.
Una vez realizada dicha limpieza, mi conda env create -f env.yml
trabajado como un encanto.