setuptools vs. distutils: ¿por qué sigue siendo distutils una cosa?

Python tiene un historial confuso de herramientas que se pueden usar para empaquetar y describir proyectos: estos incluyen distutils en la Biblioteca estándar, distribute , distutils2 y setuptools (y quizás más). Parece que distribute y distutils2 se descontinuaron en favor de setuptools , lo que deja dos estándares en competencia.

Según tengo entendido, setuptools ofrece muchas más opciones (por ejemplo, declarar dependencias, pruebas, etc.) que distutils , sin embargo, no está incluido en la biblioteca estándar de Python (¿todavía?).

La Guía del usuario de Python Packaging [ 1 ] recomienda ahora:

Utilice setuptools para definir proyectos y crear Distribuciones de Origen.

Y explica:

A pesar de que puede usar los distutils puros para muchos proyectos, no admite la definición de dependencias en otros proyectos y le faltan varias utilidades convenientes para setuptools automáticamente los metadatos de paquetes que proporciona setuptools . Al estar fuera de la biblioteca estándar, setuptools también ofrece un conjunto de funciones más consistente en diferentes versiones de Python, y (a diferencia de distutils ), setuptools se actualizará para producir los próximos formatos estándar de “Metadatos 2.0” en todas las versiones compatibles.

Incluso para los proyectos que eligen usar distutils , cuando pip instala dichos proyectos directamente desde la fuente (en lugar de instalarlos desde un archivo de rueda precomstackdo), en realidad construirá su proyecto usando setuptools .

Sin embargo, al examinar los archivos setup.py de varios proyectos se revela que esto no parece ser un estándar real. Muchos paquetes siguen utilizando distutils y los que admiten setuptools menudo combinan setuptools con distutils por ejemplo, realizando una importación alternativa:

 try: from setuptools import setup except ImportError: from distutils.core import setup 

Seguido de un bash de encontrar una forma de escribir una configuración que se pueda instalar tanto con las setuptools como con los distutils . Esto a menudo incluye varias formas de verificación de dependencias propensas a errores, ya que distutils no admite dependencias en la función de configuración.

¿Por qué la gente sigue haciendo un esfuerzo adicional para apoyar a los distutils ? ¿Es el hecho de que setuptools no está en la biblioteca estándar la única razón? ¿Cuáles son las ventajas de distutils y existen algunos inconvenientes al escribir archivos setup.py que solo admiten setuptools ?

Echa un vistazo a esta pregunta SO. Explica muy bien todos los métodos de empaquetado, y podría ayudar a responder su pregunta en cierta medida: ¿ Diferencias entre distribución, distutils, setuptools y distutils2?

Distutils sigue siendo la herramienta estándar para empaquetar en Python. Se incluye en la biblioteca estándar (Python 2 y Python 3.0 a 3.3). Es útil para distribuciones Python simples, pero carece de características. Introduce el paquete de Python distutils que se puede importar en su script setup.py.

Setuptools fue 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 paquete setuptools Python que se puede importar en su script setup.py, y el paquete pkg_resources Python que se puede importar en su código para localizar archivos de datos instalados con una distribución. Uno de sus problemas es que parchea los parches del paquete Python. Debería funcionar bien con pip. La última versión fue lanzada en julio de 2013.

Entonces, como puede ver, las herramientas de configuración deberían ser preferibles a las herramientas, y yo veo de dónde proviene su pregunta, sin embargo, no veo que las herramientas pierdan soporte en el corto plazo, ya que, simplemente, se usa en muchos casos con algunos progtwigs heredados populares. . Y como usted probablemente sepa, cambiar este tipo de cosas en progtwigs heredados puede ser un gran problema y traer algunos problemas, por ejemplo, incompatibilidades, lo que llevaría a que el desarrollador tenga que volver a escribir el código fuente. Así que existe eso, y también el hecho de que distutils es parte de la biblioteca estándar de python, mientras que setuptools no lo es. Por lo tanto, si está creando un progtwig de Python, en esta época, use setuptools, sin embargo, tenga en cuenta que sin distracciones, setuptools nunca habría existido.

es el hecho de que setuptools no está en la biblioteca estándar la única razón

Esa es una razón. Lo siguiente es directamente de NumPy setup.py :

 if len(sys.argv) >= 2 and ('--help' in sys.argv[1:] or sys.argv[1] in ('--help-commands', 'egg_info', '--version', 'clean')): # Use setuptools for these commands (they don't work well or at all # with distutils). For normal builds use distutils. try: from setuptools import setup except ImportError: from distutils.core import setup 

Así que NumPy prefiere setuptools si puede encontrarlo. Pero luego SciPy solía hacer esto, hasta que fue parcheado para preferir distutils en algunas situaciones. Citando el registro de confirmación:

 Setuptools sets mode +x on the test scripts, so that Nose refuses to run them. Better not do that. 

Por supuesto, una fusión entre las setuptools y la distribute debería resolver todo esto a su debido tiempo, pero muchos paquetes aún deben ser compatibles con las instalaciones de Python 2.6.

Hay varias razones por las que todavía hablamos y usamos distutils, a pesar de que setuptools es sin duda el mejor conjunto de herramientas.

En primer lugar, distutils está disponible en todas partes. Si está buscando construir un módulo para compartir con otros y no tiene requisitos complicados, está garantizado que esté disponible en su máquina de trabajo. Esto es particularmente importante si tiene que admitir versiones anteriores de Python o si se encuentra trabajando en un entorno desconocido.

En segundo lugar, setuptools proporciona mejoras a los nombres. Por lo tanto, se modela después del conjunto de herramientas Distutils y toma toda su estructura desde allí. La documentación de setuptools asume que el lector está familiarizado con los nombres y solo documenta cómo mejora el conjunto de herramientas base. Se puede pensar que distutils define el dialecto y setuptools mejora ese dialecto.

Mi enfoque personal para los nuevos proyectos es comenzar asumiendo que voy a utilizar distutils. Solo a medida que el proyecto crece para requerir una característica de setuptools, realizo la actualización. Setuptools es un reemplazo directo de distutils, es un cambio de una línea a mi setup.py.

Básicamente, se debe a la división de responsabilidades.

setuptools no forma parte de la biblioteca estándar de Python porque la mantiene un tercero en lugar del equipo central de Python. Lo que significa, entre otras cosas:

  • no está cubierto por el conjunto de pruebas de núcleo y no se confía en su funcionalidad central
  • no establece estándares básicos para los módulos adicionales (su ubicación, medios de importación, interfaz binaria de las extensiones C, etc.).
  • Se actualiza y lanza independientemente de las versiones de Python.

Efectivamente, el equipo central ha reducido el scope de los detalles , reservando las partes de “estándares básicos” y “comstackción mínima necesaria” para sí mismos , dejando todo lo demás más allá de eso (comstackdor extendido / formato de paquete / soporte) para terceros. El código que anteriormente cubría esas “partes extendidas” se dejó obsoleto por compatibilidad con versiones anteriores.

De la distribución de módulos de Python – documentación de Python 2.7.12 :

Si bien el uso directo de distutils se está eliminando gradualmente, aún sentó las bases de la infraestructura actual de empaquetado y distribución, y no solo sigue siendo parte de la biblioteca estándar, sino que su nombre se conserva de otras maneras (como el nombre del correo electrónico). lista utilizada para coordinar el desarrollo de estándares de empaquetamiento de Python).

Es probable que los paquetes para otros sistemas operativos proporcionen setuptools y pip separado, por las razones mencionadas anteriormente

  • y porque no son necesarios, o incluso son perjudiciales para el mantenimiento, cuando ya hay otro administrador de paquetes en el sistema.