Los paquetes de Python se alojan frecuentemente en muchos repositorios de distribución. Despues de leer este tutorial, específicamente la sección titulada "¿Realmente quieres hacer esto?" He evitado usar pip y prefiero usar el repositorio del sistema, solo recurro a pip cuando necesito instalar un paquete que no está en el repositorio.

Sin embargo, debido a que este es un método de instalación inconsistente, ¿sería mejor usar solo pip? ¿Cuáles son los beneficios / detractores para usar pip sobre el repositorio del sistema para paquetes que están disponibles en ambos lugares?

El enlace que incluí dice

La ventaja de usar siempre paquetes estándar de Debian / NeuroDebian es que los paquetes se prueban cuidadosamente para que sean compatibles entre sí. Los paquetes Debian registran dependencias con otras bibliotecas para que siempre obtenga las bibliotecas que necesita como parte de la instalación.

Yo uso el arco. ¿Es este el caso con otros sistemas de administración de paquetes además de apt?

La mayor desventaja que veo con el uso pippara instalar módulos de Python en su sistema, ya sea como módulos del 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 utilizará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á con pipversiones de los módulos administradas tanto por distribución como por distribución, 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 usted usa módulos Python, ya no puede usar el administrador de paquetes de su distribución para nada que quiera usar un módulo Python ... solo usapip

El consejo general que se brinda 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 los pipmódulos que no estén empaquetados, y cuando lo haga, hágalo en la configuración de usuario y no en el sistema. amplio. Utilice 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 anteriores; Incluso en distribuciones donde eso puede ser un problema, los entornos virtuales lo manejan con bastante facilidad.

Siempre vale la pena considerar que los paquetes de módulos y bibliotecas 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.

TL; DR

• use pip(+ virtualenv) para cosas (libs, frameworks, quizás herramientas de desarrollo) que usan sus proyectos (que desarrolla)
• use el administrador de paquetes para las aplicaciones que usa (como usuario final)

Dependencias de desarrollo

Si está desarrollando software en Python, querrá usarlo 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 mediante virtualenvwrapper o pipenv u otros medios) para separar las dependencias de diferentes proyectos entre sí y aislar las aplicaciones de Python que usa "en producción" (como usuario) de cualquier travesuras exóticas (o incluso solo incompatibilidades) que pueden continuar en desarrollo.
• Esto le permite rastrear todas las dependencias de un proyecto en un archivo requirements.txt(si su proyecto es una aplicación) o setup.py(si su proyecto es una biblioteca o marco). Esto puede verificarse en el control de revisión (por ejemplo, Git) junto con el código fuente, para que siempre sepa qué versión de su código depende de qué versiones de sus dependencias.
• Lo anterior permite a otros desarrolladores colaborar en su proyecto incluso si no usan la misma distribución de Linux o ni siquiera el mismo sistema operativo (si las dependencias usadas también están disponibles en Mac y Windows o lo que sea que usen, 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 de manera consciente y en los momentos que elija, de modo 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 siente que necesita separar las dependencias directas e indirectas (o distinguir entre el rango de versiones aceptable para una dependencia y la versión real utilizada, vea "fijación de versiones") busque herramientas-pip y / o pipenv. Esto también le permitirá distinguir entre dependencias de compilación y prueba. (La distinción entre las dependencias de compilación y tiempo de ejecución probablemente se puede codificar setup.py)

Aplicaciones que usas

Para las cosas que usa como 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 y compatible con otras cosas instaladas por el administrador de paquetes. La mayoría de las distribuciones de Linux también afirman 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 repositorios de paquetes adicionales (por ejemplo, plataforma de lanzamiento de distribuciones basadas en deb) o usar de piptodos modos. Si es lo último, úselo --userpara instalarlo en el hogar de su usuario en lugar de en todo el sistema, de modo que sea menos probable que interrumpa su instalación de Python. (Para cosas que solo necesita temporalmente o rara vez, incluso puede usar un virtualenv).

Otra razón para ir con el administrador de paquetes es que las actualizaciones se aplicarán automáticamente, lo cual es crítico para la seguridad. Piense que si el paquete de beans que Equifax usara se hubiera actualizado automáticamente a través de yum-cron-security, el hackeo podría no haber ocurrido.

En mi cuadro de desarrollo personal uso Pip, en productos utilizo 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 solo pip para instalar las cosas que ese proyecto necesita. De esa manera, instala todas las bibliotecas que usa de manera coherente, y están contenidas y no interfieren con nada de lo que instale a través de su administrador de paquetes.

Si planea lanzar algún código de Python, por lo general, 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.

Resumen

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

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

Cada nivel aquí también puede estar recibiendo apoyo de un nivel anterior. Por ejemplo, nuestro usuario en (2) puede depender de un intérprete de Python instalado a través de paquetes del sistema operativo.

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

Programas del sistema y paquetes

Los programas escritos en Python que desea "simplemente ejecutar" son fáciles: simplemente use las herramientas de instalación del sistema operativo y permita que traigan 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 las que los usuarios de su máquina pueden comenzar a confiar; Esto no es un problema siempre y cuando comprendan la dependencia e, idealmente, conozcan medios alternativos para manejarla en hosts que no proporcionan esas dependencias.

Un ejemplo común y simple de tal dependencia son algunos de mis scripts personales ~/.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) las instalaciones de Ubuntu; no lo hará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 me parece 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 generalmente dibujo la línea en las dependencias de mi sistema; todo de virtualenvadelante trato conmigo mismo. (Por ejemplo, mi script de activación estándar se basa en lo que sea pip3o pipestá en el camino, pero descarga su propia copia virtualenvpara arrancar el entorno virtual que está creando.

Dicho esto, probablemente hay circunstancias en las que es perfectamente razonable hacer más disponible un entorno de desarrollo. Es posible que tenga interfaces de Python en paquetes complejos (como un DBMS) donde desea usar la versión del sistema y cree que es mejor, también permite que el sistema elija el código de biblioteca de Python particular que usará para hablar con él. O puede estar implementando una gran cantidad de hosts con un entorno de desarrollo básico para una clase de Python, y le resulta más fácil automatizar con paquetes de sistema estándar.

Programas y paquetes "del día a día" del usuario

Los usuarios pueden tener bibliotecas o programas de Python que no encajan bien en un entorno virtual porque en primer lugar quieren ayudar a crear entornos virtuales (por ejemplo, virtualenvwrapper ) o son cosas que usualmente se usan desde la línea de comandos, incluso mientras haciendo trabajo que no sea de 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).

En general, 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 se instalen ~/.local/binpara ser el intérprete predeterminado o no) y, por supuesto, siempre se puede construir "a mano" desde la fuente si las bibliotecas de desarrollo están disponibles.

Intento mantener el conjunto mínimo de cosas instaladas aquí: virtualenvwrapper (porque lo uso constantemente) y tal vez la última versión de pip. Intento evitar dependencias fuera de la biblioteca estándar o en Python 3 para los scripts personales que escribo para ser utilizados en muchos hosts. (Aunque veremos cuánto tiempo puedo aguantar eso mientras muevo más y más de estos scripts personales a Python).

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

Esto es lo habitual de virtualenv. Para el desarrollo, casi siempre debería usar un virtualenv para asegurarse de que no está usando dependencias del sistema, o a menudo más de uno 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, generalmente configuro un virtualenv para ejecutar portátiles Jupyter y similares.