Tengo una comprensión razonable de la diferencia entre conda install
& pip install
; Cómo pip
instala los paquetes de python only y conda
puede instalar binarios que no sean de python. Sin embargo, hay una cierta superposición entre estos dos. Lo que me lleva a preguntar:
¿Cuál es la regla general para usar conda
o pip
cuando ambos ofrecen un paquete?
Por ejemplo, TensorFlow
está disponible en ambos repositorys pero desde los documentos de tensorflow :
dentro de Anaconda, recomendamos instalar TensorFlow con el comando
pip install
, no con el comandoconda install
.
Pero, hay muchos otros paquetes que se superponen, como numpy
, scipy
, etc.
Sin embargo, esta respuesta de conda install
sugiere que la conda install
debería ser la predeterminada y que solo se debe usar pip
si un paquete no está disponible desde conda
. ¿Esto es cierto incluso para TensorFlow
u otros paquetes solo para python?
Los mantenedores de Tensorflow realmente publican las ruedas de TensorFlow en PyPI, por eso es la forma oficial recomendada. Los paquetes de conda
son creados por el personal de Anaconda y / o la comunidad. Eso no significa que los paquetes de Conda sean malos, solo significa que los mantenedores de TensorFlow no participan allí (oficialmente). Básicamente, solo dicen: “Si tiene problemas para instalarlo con pip
los desarrolladores de TensorFlow intentarán ayudarlo. Pero no conda
oficialmente los paquetes de conda
, por lo que si algo sale mal con el paquete de conda, debe preguntar al conda. Mantenedores de paquetes. Has sido advertido “.
En el caso más general:
Para los paquetes solo para Python, siempre debe usar conda install
. Puede haber excepciones, por ejemplo, si no hay ningún paquete conda o si el paquete conda está desactualizado (y nadie está lanzando una nueva versión de ese paquete) y realmente necesita ese paquete / versión.
Sin embargo, es diferente para los paquetes que requieren comstackción (por ejemplo, C-Extensions, etc.). Es diferente porque con pip
puedes instalar un paquete:
Mientras que conda solo proporciona la
Con los paquetes comstackdos tienes que tener cuidado con la compatibilidad binaria. Eso significa que un paquete se comstack contra una interfaz binaria específica de otra biblioteca, lo que podría depender de la versión de las bibliotecas o las banderas de comstackción, etc.
Con conda usted tiene que tomar el paquete como está, lo que significa que debe asumir que los paquetes son compatibles con binarios. Si no lo son, no funcionará (errores de segfault o de enlace o lo que sea).
Si usa pip
y puede elegir qué rueda (si corresponde) instalar o comstackr contra las bibliotecas disponibles en su computadora. Eso significa que es menos probable que obtenga una incompatibilidad binaria. Eso es (o fue) un gran problema si instala paquetes conda de diferentes canales conda. Porque podrían ser simplemente incompatibles con los binarios (por ejemplo, conda-forge y el canal de anaconda tienen o tuvieron algunos problemas allí).
Sin embargo, probablemente debería decidirse caso por caso. No tuve problemas con mi entorno tensorflow
conda donde instalé todos los paquetes del canal conda-forge
, incluido tensorflow. Sin embargo, he escuchado que varias personas tuvieron problemas con el tensorflow en conda-forge
mixtos de conda-forge
y anaconda
. Por ejemplo, NumPy del canal principal y TensorFlow del canal conda-forge podrían ser incompatibles con los binarios.
Mi regla de oro es:
conda install
desde un solo canal (si es posible el canal principal de anaconda). Preguntó por qué no puede instalar paquetes desde PyPI con conda
. No sé las razones exactas, pero pip
proporciona principalmente el paquete y usted tiene que instalarlo usted mismo. Con conda usted obtiene un paquete ya comstackdo e instalado que simplemente se “copia” sin instalación. Eso requiere que el paquete se instale en diferentes sistemas operativos (Mac, Windows, Linux) y en plataformas (32 bits, 64 bits), contra diferentes versiones de Python (2.7, 3.5, 3.6) y posiblemente contra diferentes versiones de NumPy. Eso significa que Conda tiene que proporcionar varios paquetes en lugar de solo uno. Eso requiere recursos (espacio para los paquetes finales instalados y tiempo para la instalación) que probablemente no estén disponibles o no sean factibles. Aparte de eso, es probable que no haya un convertidor para un paquete pypi a una receta de conda, aparte de todos los detalles que debe conocer sobre un paquete (comstackción, instalación) para que funcione. Eso es solo mi conjetura sin embargo.