La mayor desventaja que veo con el uso de pippara instalar módulos de Python en su sistema, ya sea como módulos de sistema o como módulos de usuario, es que el sistema de administración de paquetes de su distribución no los conocerá. Esto significa que no se usarán para ningún otro paquete que los necesite y que desee instalar en el futuro (o que pueda comenzar a usar uno de esos módulos después de una actualización ); luego terminará conpip-y versiones administradas de distribución -de los módulos, lo que puede causar problemas (Me encontré con otra instancia de esto recientemente ). Entonces, su pregunta termina siendo una propuesta de todo -o -nada :si solo usa pippara los módulos de Python, ya no puede usar el administrador de paquetes de su distribución para cualquier cosa que quiera para usar un módulo Python...

El consejo general dado en la página a la que se vinculó es muy bueno :intente usar los paquetes de su distribución en la medida de lo posible, solo use pippara módulos que no están empaquetados, y cuando lo haga, hágalo en su configuración de usuario y no en todo el sistema -. Utilizar entornos virtuales en la medida de lo posible, en particular para el desarrollo de módulos. Especialmente en Arch, no debería encontrarse con problemas causados ​​por módulos más antiguos; incluso en distribuciones donde eso puede ser un problema, los entornos virtuales lo solucionan con bastante facilidad.

Siempre vale la pena considerar que la biblioteca y los paquetes de módulos de una distribución se empaquetan principalmente para el uso de otros paquetes en la distribución; tenerlos alrededor es un buen efecto secundario -para el desarrollo usando esas bibliotecas y módulos, pero ese no es el caso de uso principal -.

Otra razón para optar por el administrador de paquetes es que las actualizaciones se aplicarán automáticamente, lo cual es fundamental para la seguridad. Piense si el paquete de frijoles que utilizó Equifax se hubiera actualizado automáticamente a través de yum -cron -seguridad,el hack puede no haber ocurrido.

En mi caja de desarrollo personal uso Pip, en producción uso paquetes.

Si estamos hablando de instalar paquetes de python para usar en el código que está escribiendo, use pip.

Para cada proyecto en el que esté trabajando, cree un entorno virtual y luego use pip solo para instalar las cosas que necesita ese proyecto. De esa manera, instala todas las bibliotecas que usa de manera consistente, están contenidas y no interfieren con nada de lo que instala a través de su administrador de paquetes.

Si planea lanzar cualquier código de Python, normalmente agregará un setup.pyo requirements.txta su proyecto, lo que permitirá que pip obtenga automáticamente todas sus dependencias. Permitiéndole crear o recrear fácilmente un entorno virtual para ese proyecto.

TL; DR

• usapip(+ virtualenv )para cosas (libs, frameworks, tal vez herramientas de desarrollo)tus proyectos(que desarrollas )usa
• usa el administrador de paquetes para aplicaciones tú usas (como usuario final -)

Dependencias de desarrollo

Si está desarrollando software en Python, querrá usar pippara todas las dependencias del proyecto, ya sean dependencias de tiempo de ejecución, dependencias de tiempo de construcción -o cosas necesarias para pruebas automatizadas y verificaciones de cumplimiento automatizadas (linter, verificador de estilo, verificador de tipo estático...)

Hay varias razones para esto:

• Esto le permite usar virtualenv(ya sea directamente o a través de virtualenvwrapper o pipenv u otros medios )para separar las dependencias de diferentes proyectos entre sí y para aislar las aplicaciones de python que usa "en producción" (como usuario )de cualquier travesura exótica (o incluso incompatibilidades )que puedan ocurrir en el desarrollo.
• Esto le permite rastrear todas las dependencias de un proyecto en un archivorequirements.txt(si su proyecto es una aplicación )osetup.py(si su proyecto es una biblioteca o un marco ). Esto se puede verificar en el control de revisión (, p. Git )junto con el código fuente, para que siempre sepa qué versión de su código se basó en qué versiones de sus dependencias.
• Lo anterior permite que otros desarrolladores colaboren en su proyecto incluso si no usan la misma distribución de Linux o ni siquiera el mismo sistema operativo (si las dependencias utilizadas también están disponibles en Mac y Windows o lo que sea. usar,eso es)
• No desea que las actualizaciones automáticas del administrador de paquetes de su sistema operativo rompan su código. Debe actualizar sus dependencias, pero debe hacerlo conscientemente y en los momentos que elija, para que pueda estar listo para corregir su código o revertir la actualización. (Lo cual es fácil si realiza un seguimiento de la declaración de dependencia completa en su sistema de control de revisión, junto con su código.)

Si cree que necesita separar las dependencias directas e indirectas (o distinguir entre el rango de versión aceptable para una dependencia y la versión real utilizada, cf. "fijación de versión" )mire las herramientas pip -y/o pipenv. Esto también le permitirá distinguir entre dependencias de compilación y de prueba. (La distinción entre dependencias de compilación y tiempo de ejecución probablemente se pueda codificar ensetup.py)

Aplicaciones que utiliza

Para las cosas que usa como una aplicación normal y que simplemente están escritas en Python, prefiera el administrador de paquetes de su sistema operativo. Se asegurará de que se mantenga razonablemente actualizado -a -y sea compatible con otras cosas instaladas por el administrador de paquetes. La mayoría de las distribuciones de Linux también afirmarán que no distribuyen ningún malware.

Si algo que necesita no está disponible en el repositorio de paquetes predeterminado de su distribución, puede consultar los repositorios de paquetes adicionales (, p. plataforma de lanzamiento de distribuciones basadas en deb -)o use pipde todos modos. Si es lo último, use --userpara instalarlo en la casa de su usuario en lugar de en todo el sistema -, para que sea menos probable que rompa su instalación de Python. (Para cosas que solo necesita temporalmente o rara vez, puede incluso usar un virtualenv.)

Resumen

Hay tres categorías generales de módulos con los que está tratando:

1. Esos programas de soporte instalados para todos los usuarios con el sistema de paquetes OS. (Esto puede incluso incluir herramientas y bibliotecas utilizadas por personas que programan en Python; vea abajo. )Para esto, usa los paquetes del sistema operativo donde puede, y pipse instala en los directorios del sistema donde sea necesario.
2. Esos programas de soporte instalados por un usuario en particular solo para su propio uso, y también para ciertos aspectos de su uso "día -a -día" de Python como lenguaje de secuencias de comandos. Para estos utiliza pip --user, quizás pyenv o pythonz , y herramientas y tácticas similares.
3. Aquellos que apoyan el desarrollo y uso de una aplicación específica. Para esto, usavirtualenv(o una herramienta similar ).

Cada nivel aquí también puede recibir apoyo de un nivel anterior. Por ejemplo, nuestro usuario en (2 )puede estar confiando en un intérprete de Python instalado a través de paquetes de SO.

Entrando en esto con un poco más de detalle:

Programas y paquetes del sistema

Los programas escritos en Python que desea "simplemente ejecutar" son fáciles :simplemente use las herramientas de instalación del sistema operativo y déjelos traer lo que necesiten; esto no es diferente de un programa que no sea -Python. ¡Es probable que esto traiga herramientas/bibliotecas de Python (como el propio intérprete de Python! )en el que los usuarios de su máquina pueden comenzar a confiar;esto no es un problema siempre que entiendan la dependencia e, idealmente, conozcan medios alternativos para manejarla en hosts que no proporcionen esas dependencias.

Un ejemplo común y simple de tal dependencia son algunos de mis scripts personales en ~/.local/bin/que comienzan con #!/usr/bin/env python. Estos funcionarán bien (siempre que se ejecuten bajo Python 2 )en RH/CentOS 7 y la mayoría (pero no todas )instalaciones de Ubuntu; no estarán bajo una instalación básica de Debian o en Windows. Por mucho que no me guste que mi entorno personal tenga muchas dependencias en los paquetes del sistema operativo (, trabajo en varios sistemas operativos diferentes ), algo como esto lo encuentro bastante aceptable; mi plan de respaldo en los hosts raros que no tienen un sistema Python y no pueden obtener uno es ir con un sistema de usuario como se describe a continuación.

Las personas que usan un intérprete de Python del sistema también suelen depender del sistema pip3. Ahí es donde normalmente trazo la línea en las dependencias de mi sistema; todo de virtualenven adelante me ocupo de mí mismo. (Por ejemplo, mi secuencia de comandos de activación estándar se basa en cualquier pip3o pipque esté en la ruta, pero descarga su propia copia de virtualenvpara iniciar el entorno virtual que está creando.

Dicho esto, es probable que haya circunstancias en las que sea perfectamente razonable hacer más disponible un entorno de desarrollo. Es posible que tenga interfaces de Python en paquetes complejos (como un DBMS )en el que quiera usar la versión del sistema y sienta que es mejor que también deje que el sistema elija el código de la biblioteca de Python en particular que usará para hablar lo. O puede estar implementando una gran cantidad de hosts con un entorno de desarrollo básico para una clase de Python y encontrarlo más fácil de automatizar con paquetes de sistema estándar.

Usuario "Día -a -día" Programas y Paquetes

Los usuarios pueden tener bibliotecas o programas de Python que no se adaptan bien a un entorno virtual porque, en primer lugar, quieren ayudar a crear entornos virtuales (, por ejemplo, virtualenvwrapper)o son cosas que usa comúnmente desde la línea de comandos, incluso cuando no trabaja con Python -. Incluso si tienen la capacidad de instalar versiones del sistema de estos, pueden sentirse más cómodos instalando los suyos propios (, por ejemplo, porque quieren usar la última versión de la herramienta y sus dependencias ).

Generalmente pip --useres lo que la gente usará para esto, aunque ciertas dependencias, como el propio intérprete de Python, requieren un poco más que eso. pyenv y pythonz son ​​útiles para construir intérpretes personales (ya sea que estén instalados en ~/.local/binpara ser el intérprete predeterminado o de otra manera )y, por supuesto, uno siempre puede simplemente construir " a mano" de la fuente si las bibliotecas de desarrollo están disponibles.

Trato de mantener el conjunto mínimo de cosas instaladas aquí :virtualenvwrapper (porque lo uso constantemente )y quizás la última versión de pip. Trato de evitar dependencias fuera de la biblioteca estándar o en Python 3 para scripts personales que escribo para ser usados ​​en muchos hosts. (Aunque veremos cuánto tiempo aguanto con eso a medida que muevo más y más de estos scripts personales a Python.)

Desarrollo de aplicaciones y entornos de tiempo de ejecución independientes

Esto es lo habitual virtualenv. Para el desarrollo, casi siempre debe usar un virtualenv para asegurarse de que no está usando dependencias del sistema o, a menudo, más de una para probar diferentes versiones de Python.

Estos entornos virtuales también son buenos para aplicaciones con muchas dependencias en las que desea evitar contaminar su entorno de usuario.Por ejemplo, normalmente configuro un virtualenv para ejecutar portátiles Jupyter y similares.