¿Por qué usar pip sobre easy_install?

Un tweet lee:

No uses easy_install, a menos que te guste apuñalarte en la cara. Utilice pip.

¿Por qué usar pip sobre easy_install? ¿No es la culpa principalmente de PyPI y de los autores de paquetes ? Si un autor carga un archivo fuente de basura (por ejemplo: archivos que faltan, no hay setup.py) en PyPI, entonces pip y easy_install fallarán. Aparte de las diferencias estéticas, ¿por qué las personas de Python (como en el tweet anterior) parecen favorecer fuertemente a pip en lugar de easy_install?

(Supongamos que estamos hablando de easy_install del paquete Distribute, que es mantenido por la comunidad)

    Muchas de las respuestas aquí están desactualizadas para 2015 (aunque la aceptada inicialmente por Daniel Roseman no lo está). Aquí está el estado actual de las cosas:

    • Los paquetes binarios ahora se distribuyen como ruedas (archivos .whl ), no solo en PyPI, sino en repositorys de terceros como los Paquetes de Extensión para Windows de Christoph Gohlke . pip puede manejar ruedas; easy_install no puede.
    • Los entornos virtuales (que vienen incorporados con 3.4, o se pueden agregar a 2.6 + / 3.1 + con virtualenv ) se han convertido en una herramienta muy importante y prominente (y se recomiendan en los documentos oficiales ); incluyen pip fuera de la caja, pero ni siquiera funcionan correctamente con easy_install .
    • El paquete de distribute que incluía easy_install ya no se mantiene. Sus mejoras sobre setuptools se fusionaron de nuevo en setuptools . Intentar instalar distribute simplemente instalará setuptools en setuptools lugar.
    • easy_install sí mismo es solo cuasi mantenido.
    • Todos los casos en los que pip solía ser inferior a la instalación easy_install instalación desde un árbol de origen desempaquetado, desde un repository de DVCS, etc.) son obsoletos; puedes pip install . , pip install git+https:// .
    • pip viene con los paquetes oficiales de Python 2.7 y 3.4+ de python.org, y se incluye de forma predeterminada un bootstrap de pip si se construye desde la fuente.
    • Los diversos bits incompletos de la documentación sobre la instalación, el uso y la creación de paquetes han sido reemplazados por la Guía del usuario de Python Packaging . La propia documentación de Python sobre la instalación de módulos de Python ahora se refiere a esta guía del usuario y explícitamente llama a pip como “el progtwig de instalación preferido”.
    • A lo largo de los años se agregaron otras características nuevas que nunca estarán disponibles en easy_install . Por ejemplo, pip facilita la clonación de sus paquetes de sitio al crear un archivo de requisitos y luego instalarlo con un solo comando en cada lado. O para convertir su archivo de requisitos a un repository local para usarlo en el desarrollo interno. Y así.

    La única buena razón que conozco para usar easy_install en 2015 es el caso especial de usar las versiones de Python preinstaladas de Apple con OS X 10.5-10.8. Desde 10.5, Apple ha incluido easy_install , pero a partir de 10.10 todavía no incluyen pip . Con 10.9+, aún debe usar get-pip.py , pero para 10.5-10.8, esto tiene algunos problemas, por lo que es más fácil sudo easy_install pip . (En general, easy_install pip es una mala idea; solo es para OS X 10.5-10.8 que quieres hacer esto). Además, 10.5-10.8 incluye readline de una manera que easy_install sabe cómo easy_install el easy_install pero pip no. por lo que también desea sudo easy_install readline si desea actualizar eso.

    De la propia introducción de Ian Bicking a pip :

    pip fue escrito originalmente para mejorar en easy_install de las siguientes maneras

    • Todos los paquetes se descargan antes de la instalación. La instalación parcialmente completada no se produce como resultado.
    • Se tiene cuidado de presentar resultados útiles en la consola.
    • Las razones de las acciones son seguidas. Por ejemplo, si se está instalando un paquete, pip realiza un seguimiento de por qué se requirió ese paquete.
    • Los mensajes de error deberían ser útiles.
    • El código es relativamente conciso y cohesivo, lo que facilita su uso programático.
    • Los paquetes no tienen que instalarse como archivos de huevo, se pueden instalar planos (manteniendo los metadatos del huevo).
    • Soporte nativo para otros sistemas de control de versiones (Git, Mercurial y Bazaar)
    • Desinstalación de paquetes.
    • Simple para definir conjuntos fijos de requisitos y reproducir de manera confiable un conjunto de paquetes.

    Otra razón, aún no mencionada, de favorecer a pip es que es el nuevo hotness y se seguirá utilizando en el futuro.

    La siguiente infografía, de la sección Estado actual del empaque en la Guía del autoestopista para el empaque v1.0, muestra que setuptools / easy_install desaparecerá en el futuro.

    introduzca la descripción de la imagen aquí

    Aquí hay otra infografía de la documentación de distribución que muestra que Setuptools y easy_install serán reemplazados por el nuevo hotness: distribuya y descarte. Si bien pip sigue siendo el nuevo hotness, Distribute se fusionó con Setuptools en 2013 con el lanzamiento de Setuptools v0.7.

    introduzca la descripción de la imagen aquí

    Dos razones, puede haber más:

    1. pip proporciona un comando de uninstall

    2. Si una instalación falla en el medio, pip te dejará en un estado limpio.

    REQUISITOS de archivos.

    En serio, lo uso junto con virtualenv todos los días.


    TUTORIAL DE GESTIÓN DE DEPENDENCIA RÁPIDA, FOLKS

    Los archivos de requisitos le permiten crear una instantánea de todos los paquetes que se han instalado a través de pip. Al encapsular esos paquetes en un entorno virtual, puede hacer que su base de código funcione en un conjunto muy específico de paquetes y compartir esa base de código con otros.

    De la documentación de Heroku https://devcenter.heroku.com/articles/python

    Crea un entorno virtual y configura su shell para que lo use. (bash / * nix instrucciones)

     virtualenv env source env/bin/activate 

    Ahora todos los scripts de Python que se ejecutan con este shell utilizarán los paquetes y la configuración de este entorno. Ahora puede instalar un paquete localmente en este entorno sin necesidad de instalarlo globalmente en su máquina.

     pip install flask 

    Ahora puede volcar la información sobre qué paquetes se instalan con

     pip freeze > requirements.txt 

    Si incluyó ese archivo en el control de versiones, cuando alguien más obtenga su código, podrá configurar su propio entorno virtual e instalar todas las dependencias con:

     pip install -r requirements.txt 

    Cada vez que puedes automatizar el tedio como este es impresionante.

    pip no instalará paquetes binarios y no está bien probado en Windows.

    Como Windows no viene con un comstackdor por defecto, el pip a menudo no se puede usar allí. easy_install puede instalar paquetes binarios para Windows.

    ACTUALIZACIÓN: setuptools ha absorbido distribute en lugar de lo contrario, como algunos pensaron. setuptools está actualizado con los últimos cambios de distutils y el formato de la rueda. Por lo tanto, easy_install y pip están más o menos en pie de igualdad ahora.

    Fuente: http://pythonhosted.org/setuptools/merge-faq.html#why-setuptools-and-not-distribute-or-another-name

    Como una adición a la respuesta de Fuzzyman:

    pip no instalará paquetes binarios y no está bien probado en Windows.

    Como Windows no viene con un comstackdor por defecto, el pip a menudo no se puede usar allí. easy_install puede instalar paquetes binarios para Windows.

    Aquí hay un truco en Windows:

    • puede usar easy_install para instalar paquetes binarios para evitar la creación de un binario

    • puede utilizar pip uninstall incluso si usó easy_install.

    Esto es solo una solución que me funciona en Windows. En realidad siempre uso pip si no hay binarios involucrados.

    Consulte el actual pip doku: http://www.pip-installer.org/en/latest/other-tools.html#pip-compared-to-easy-install

    Preguntaré en la lista de correo qué está planeado para eso.

    Aquí está la última actualización:

    La nueva forma soportada de instalar binarios será la wheel ! Todavía no está en el estándar, pero casi. La versión actual sigue siendo un alfa: 1.0.0a1

    https://pypi.python.org/pypi/wheel

    http://wheel.readthedocs.org/en/latest/

    Voy a probar la wheel creando un instalador OS X para PySide usando la wheel lugar de los huevos. Volveré e informar sobre esto.

    Saludos – Chris

    Una actualización rápida:

    La transición a la wheel está casi terminada. La mayoría de los paquetes son compatibles con la wheel .

    Prometí construir ruedas para PySide , y lo hice el verano pasado. ¡Funciona genial!

    SUGERENCIA: algunos desarrolladores fallaron hasta ahora para admitir el formato de rueda, simplemente porque se olvidan de reemplazar las distutils de setuptools por setuptools . A menudo, es fácil convertir estos paquetes reemplazando esta sola palabra en setup.py .

    Acabo de conocer un caso especial que tuve que usar easy_install lugar de pip , o tengo que extraer los códigos fuente directamente.

    Para el paquete GitPython , la versión en pip es demasiado antigua, que es 0.1.7 , mientras que la de easy_install es la última, que es 0.3.2.rc1 .

    Estoy usando Python 2.7.8 . No estoy seguro del mecanismo subyacente de easy_install y pip , pero al menos las versiones de algunos paquetes pueden ser diferentes entre sí, y a veces easy_install es la que tiene una versión más nueva.

     easy_install GitPython