¿Diferencias entre distribuir, distutils, setuptools y distutils2?

La situación

Estoy tratando de portar una biblioteca de código abierto a Python 3. ( SymPy , si alguien se lo pregunta).

Entonces, necesito ejecutar 2to3automáticamente cuando compilo para Python 3. Para hacer eso, necesito usar distribute. Por lo tanto, necesito portar el sistema actual, que (según el doctest) es distutils.

El problema

Por desgracia, no estoy seguro de cuál es la diferencia entre estos Modules- distutils, distribute, setuptools. La documentación es incompleta como la mejor, ya que todos parecen ser una bifurcación entre sí, destinados a ser compatibles en la mayoría de las circunstancias (pero en realidad, no todas) ... y así sucesivamente.

La pregunta

¿Alguien podría explicar las diferencias? ¿Qué se supone que debo usar? ¿Cuál es la solución más moderna? (Por otro lado, también agradecería alguna guía sobre la portabilidad Distribute, pero eso está un poco más allá del alcance de la pregunta ...)

A partir de marzo de 2020, la mayoría de las otras respuestas a esta pregunta están desactualizadas varios años. Cuando encuentre consejos sobre problemas de empaquetado de Python, recuerde consultar la fecha de publicación y no confíe en la información desactualizada.

El Python Guía del usuario Embalaje es digno de una lectura. Cada página muestra una fecha de "última actualización", por lo que puede verificar la actualidad del manual, y es bastante completo. El hecho de que esté alojado en un subdominio de python.org de la Python Software Foundation solo le da crédito. La página de Resúmenes de proyectos es especialmente relevante aquí.

Resumen de herramientas:

Aquí hay un resumen del panorama del empaque de Python:

Herramientas compatibles:

• distutilssigue siendo la herramienta estándar para empaquetar en Python. Se incluye en la biblioteca estándar (Python 2 y Python 3). Es útil para distribuciones simples de Python, pero carece de características. Presenta el distutilspaquete Python que se puede importar en su setup.pyscript.

  • _{Documentos oficiales | distutilssección de la Guía del usuario del paquete Python}

• setuptoolsfue desarrollado para superar las limitaciones de Distutils y no está incluido en la biblioteca estándar. Introdujo una utilidad de línea de comandos llamada easy_install. También introdujo el setuptoolspaquete Python que se puede importar en su setup.pyscript, y el pkg_resourcespaquete Python que se puede importar en su código para ubicar los archivos de datos instalados con una distribución. Una de sus trampas es que parchea el distutilspaquete Python. Debería funcionar bien con pip. Ve lanzamientos regulares.

  • _{Documentos oficiales | Página de Pypi | Repositorio de GitHub | setuptoolssección de la Guía del usuario del paquete Python}

• scikit-buildes un generador de sistema de compilación mejorado que utiliza internamente CMake para compilar extensiones compiladas de Python. Debido a que scikit-build no se basa en distutils, en realidad no tiene ninguna de sus limitaciones. Cuando ninja-build está presente, scikit-build puede compilar grandes proyectos más de tres veces más rápido que las alternativas. Debería funcionar bien con pip.

  • _{Documentos oficiales | Página de Pypi | Repositorio de GitHub | scikit-buildsección de la Guía del usuario del paquete Python}

• distlibes una biblioteca que proporciona funcionalidad utilizada por herramientas de nivel superior como pip.

  • _{Documentos oficiales | Página de Pypi | Repo de Bitbucket | distlibsección de la Guía del usuario del paquete Python}

• packagingtambién es una biblioteca que proporciona funcionalidad utilizada por herramientas de nivel superior como pipysetuptools

  • _{Documentos oficiales | Página de Pypi | Repositorio de GitHub | packagingsección de la Guía del usuario del paquete Python}

Herramientas obsoletas / abandonadas:

• distributefue un tenedor de setuptools. Compartía el mismo espacio de nombres, por lo que si tuviera instalado Distribute, en import setuptoolsrealidad importaría el paquete distribuido con Distribute. Distribuir se fusionó nuevamente en Setuptools 0.7 , por lo que ya no necesita usar Distribuir. De hecho, la versión en Pypi es solo una capa de compatibilidad que instala Setuptools.

• distutils2fue un intento de tomar lo mejor de distutils, setuptoolsy distributey convertirse en la herramienta estándar incluida en la biblioteca estándar de Python. La idea era que distutils2se distribuiría para las versiones antiguas de Python, y que distutils2se renombraría packagingpara Python 3.3, que lo incluiría en su biblioteca estándar. Sin embargo, estos planes no salieron según lo previsto, y actualmente distutils2es un proyecto abandonado . El último lanzamiento fue en marzo de 2012, y su página de inicio de Pypi finalmente se actualizó para reflejar su muerte.

Otros:

Existen otras herramientas, si está interesado, lea Resúmenes de proyectos en la Guía del usuario de Python Packaging. No voy a enumerarlas todas, para no repetir esa página, y para mantener la respuesta a la pregunta a juego, que era sólo alrededor de distribute, distutils, setuptoolsy distutils2.

Recomendación:

Si todo esto es nuevo para usted, y no sabe por dónde comenzar, recomendaría aprendersetuptools , junto con pipy virtualenv, que funcionan muy bien juntos.

Si usted está buscando en virtualenv, que podría estar interesado en esta pregunta: ¿Cuál es la diferencia entre venv, pyvenv, pyenv, virtualenv, virtualenvwrapper, etc? . (Sí, lo sé, gimo contigo)

Soy mantenedor de distutils y colaborador de distutils2 / packaging. Hice una charla sobre el empaquetado de Python en ConFoo 2011 y en estos días estoy escribiendo una versión extendida del mismo. Todavía no está publicado, así que aquí hay extractos que deberían ayudar a definir las cosas.

• Distutils es la herramienta estándar utilizada para el embalaje. Funciona bastante bien para necesidades simples, pero es limitado y no es trivial de extender.

• Setuptools es un proyecto nacido del deseo de llenar la funcionalidad distutils que falta y explorar nuevas direcciones. En algunas subcomunidades, es un estándar de facto . Utiliza parches de mono y magia mal vista por los desarrolladores centrales de Python.

• Distribuir es una bifurcación de Setuptools que los desarrolladores iniciaron sintiendo que su ritmo de desarrollo era demasiado lento y que no era posible evolucionarlo. Su desarrollo se ralentizó considerablemente cuando distutils2 fue iniciado por el mismo grupo. Actualización 2013-agosto: la distribución se fusiona nuevamente en las herramientas de configuración y se suspende.

• Distutils2 es una nueva biblioteca de distutils, que comenzó como una bifurcación de la base de código de distutils, con buenas ideas tomadas de las herramientas de configuración (algunas de las cuales se discutieron a fondo en PEP) y un instalador básico inspirado en pip. El nombre real que usa para importar Distutils2 está packagingen la biblioteca estándar Python 3.3+, o distutils2en 2.4+ y 3.1–3.2. (Un backport estará disponible pronto). Distutils2 no realizó la versión Python 3.3, y se puso en espera.

Más información:

• El destino de Distutils - Informe detallado de Pycon Summit + Packaging Sprint
• Una diferencia rápida entre Distutils y Distutils2

Espero terminar mi guía pronto, contendrá más información sobre los puntos fuertes y débiles de cada biblioteca y una guía de transición.

NOTA: Respuesta en desuso, Distribuir ahora obsoleto. Esta respuesta ya no es válida ya que se formó la Autoridad de Empaque de Python y ha trabajado mucho para limpiar esto.

Sí, lo tienes. : -o Creo que en este momento el paquete preferido es Distribuir , que es una bifurcación de herramientas de configuración, que son una extensión de distutils (el sistema de empaquetado original). Setuptools no se mantenía, por lo que se bifurcó y cambió de nombre, sin embargo, cuando se instala, utiliza el nombre del paquete de setuptools. Creo que la mayoría de los desarrolladores de Python ahora usan Distribute, y puedo decir con certeza que sí.

Me doy cuenta de que he respondido a su pregunta secundaria sin abordar suposiciones incuestionables en su problema original:

Estoy tratando de portar una biblioteca de código abierto (SymPy, si alguien se lo pregunta) a Python 3. Para hacer esto, necesito ejecutar 2to3 automáticamente cuando compilo para Python 3.

Puede que no lo necesite . Otras estrategias se describen en http://docs.python.org/dev/howto/pyporting

Para hacer eso, necesito usar distribuir,

Usted puede :) distutils conversión 2to3 soportes-tiempo de construcción de código (no docstrings), de una manera diferente que distribuyen de: http://docs.python.org/dev/howto/pyporting#during-installation

Actualizando esta pregunta a fines de 2014, donde afortunadamente el caos de empaquetado de Python ha sido limpiado en gran medida por el administrador de paquetes " conda " de Continuum .

En particular, conda permite rápidamente la creación de " entornos " conda . Puede configurar sus entornos con diferentes versiones de Python. Por ejemplo:

conda create -n py34 python=3.4 anaconda

conda create -n py26 python=2.6 anaconda

creará dos entornos Python ("py34" o "py26") con diferentes versiones de Python.

Luego puede invocar el entorno con la versión específica de Python con:

source activate <env name>

Esta característica parece especialmente útil en su caso en el que tiene que lidiar con diferentes versiones de Python.

Además, conda tiene las siguientes características:

• Python agnóstico
• Plataforma cruzada
• No se requieren privilegios de administrador
• Gestión inteligente de dependencias (por medio de un solucionador SAT)
• Trata muy bien con C, Fortran y bibliotecas de nivel de sistema con las que puede tener que vincular

Ese último punto es especialmente importante si estás en el campo de la computación científica.