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

Python tiene una confusa historia de las herramientas que se pueden utilizar para empaquetar y describir los proyectos: se completan distutilsen la librería estándar, distribute, distutils2, y setuptools(y tal vez más). Parece que distributey distutils2fueron descontinuados a favor de setuptools, lo que deja dos estándares en competencia.

Según tengo entendido, setuptoolsofrece 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:

Úselo setuptoolspara definir proyectos y crear Distribuciones de origen.

Y explica:

Aunque puede usar puro distutilspara muchos proyectos, no admite la definición de dependencias en otros proyectos y le faltan varias utilidades de conveniencia para completar automáticamente los metadatos del paquete proporcionados por setuptools. Al estar fuera de la biblioteca estándar, setuptools también ofrece un conjunto de características más consistente en diferentes versiones de Python, y (a diferencia de distutils), setuptoolsse actualizará para producir los próximos formatos estándar "Metadata 2.0" en todas las versiones compatibles.

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

Sin embargo, mirar los archivos setup.py de varios proyectos revela que esto no parece ser un estándar real. Todavía se usan muchos paquetes distutilsy los que admiten a setuptoolsmenudo se mezclan, setuptoolspor distutilsejemplo, haciendo una importación alternativa:

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

Seguido de un intento de encontrar una manera de escribir una configuración que pueda ser instalada por ambos setuptoolsy distutils. Esto a menudo incluye varias formas de comprobación de dependencias propensas a errores, ya distutilsque no admite dependencias en la función de configuración.

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

Echa un vistazo a esta pregunta SO. Explica todos los métodos de empaque muy bien y podría ayudar a responder su pregunta hasta cierto punto: ¿ Diferencias entre distribuir, 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 simples de Python, pero carece de características. Presenta el paquete Python distutils que puede importarse 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 Python setuptools que se puede importar en su script setup.py, y el paquete Python pkg_resources 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 el paquete Python distutils. Debería funcionar bien con pip. La última versión se lanzó en julio de 2013.

Entonces, como puede ver, las herramientas de configuración deberían preferirse a distutils, y veo de dónde proviene su pregunta, sin embargo, no veo que distutils pierda soporte en el corto plazo, ya que, simplemente, se usa en muchos casos con algunos programas heredados populares . Y, como probablemente sepa, cambiar este tipo de cosas en los programas heredados puede ser bastante difícil y puede tener bastantes problemas, por ejemplo, incompatibilidades, lo que llevaría al desarrollador a tener que volver a escribir el código fuente. Así que está 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 programa de Python, hoy en día, use setuptools, sin embargo, tenga en cuenta que sin distutils, setuptools nunca hubiera existido.

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

Esa es una de las razones. Lo siguiente es directo de NumPysetup.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

Entonces NumPy prefiere setuptools si puede encontrarlo. Pero entonces SciPy solía hacer esto, hasta que fue parchado para preferir distutilsen 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 setuptoolsy distributedebería resolver todo esto a su debido tiempo, pero muchos paquetes aún necesitan soportar las instalaciones de Python 2.6.

Hay varias razones por las que todavía hablamos y usamos distutils, aunque 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 estará disponible en su máquina de trabajo. Esto es particularmente importante si tiene que soportar versiones anteriores de python, o si se encuentra trabajando en un entorno desconocido.

En segundo lugar, setuptools proporciona mejoras a distutils. Por lo tanto, está modelado a partir del conjunto de herramientas distutils y toma toda su estructura desde allí. La documentación de setuptools asume que el lector está familiarizado con distutils y solo documenta cómo mejora el conjunto de herramientas base. Puede pensar que distutils define el dialecto y que setuptools mejora ese dialecto.

Mi enfoque personal para nuevos proyectos es comenzar con la suposición de que voy a usar distutils. Solo cuando el proyecto crece para requerir una función de herramientas de configuración hago la actualización. Setuptools es un reemplazo directo para distutils, es un cambio de una línea a mi setup.py.

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

setuptoolsno es parte de la biblioteca estándar de Python porque es mantenida por un tercero en lugar del equipo central de Python. Lo que significa, entre otras cosas:

• no está cubierto por el conjunto de pruebas del núcleo y no está basado en la funcionalidad del núcleo
• no en sí establece normas básicas para módulos adicionales (su localización, medios de importación, C extensiones binario interfaz etc.).
• se actualiza y se libera independientemente de las versiones de Python

Efectivamente, el equipo central ha reducido el alcance de distutils , reservando los "estándares básicos" y las partes de "compilación mínima necesaria" para sí mismos mientras deja todo lo demás más allá de eso (compilador extendido / formato de paquete / cualquier soporte) a terceros. El código que anteriormente cubría esas "partes extendidas" quedó obsoleto por compatibilidad con versiones anteriores.

Desde la distribución de módulos de Python : documentación de Python 2.7.12 :

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

También es probable que los paquetes para otros sistemas operativos proporcionen setuptoolsy por pipseparado, por los motivos antes mencionados

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