setuptools vs. distutils: ¿por qué distutils sigue existiendo?

Python tiene una historia confusa de herramientas que se pueden usar para empaquetar y describir proyectos: estos incluyen distutils en la biblioteca estándar, distribute, distutils2y setuptools (y tal vez más). Parece que distribute y distutils2 fueron descontinuados a favor de setuptoolslo que deja dos estándares en competencia.

A mi entender setuptools ofrece muchas más opciones (por ejemplo, declaración de dependencias, pruebas, etc.) que distutilssin embargo, no está incluido en la biblioteca estándar de Python (¿todavía?).

los Guía del usuario de empaquetado de Python[1] recomienda ahora:

Usar setuptools para definir proyectos y crear distribuciones de origen.

Y explica:

Aunque puedes usar puro distutils para muchos proyectos, no admite la definición de dependencias en otros proyectos y faltan varias utilidades convenientes para completar automáticamente los metadatos del paquete correctamente que son proporcionados por 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 “Metadatos 2.0” en todas las versiones compatibles.

Incluso para proyectos que eligen usar distutilscuando pip instala dichos proyectos directamente desde la fuente (en lugar de instalar desde un archivo de rueda preconstruido), en realidad construirá su proyecto usando setuptools en cambio.

Sin embargo, al examinar varios proyectos configuración.py files revela que esto no parece ser un estándar real. Muchos paquetes todavía usan distutils y los que apoyan setuptools a menudo se mezclan setuptools con distutils por ejemplo, haciendo una importación alternativa:

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

Seguido por un intento de encontrar una manera de escribir una configuración que pueda ser instalada por ambos setuptools y distutils. Esto a menudo incluye varias formas de verificación de dependencia propensa 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 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 hay algún inconveniente de escribir configuración.py archivos que solo admiten setuptools.

Eche un vistazo a esta pregunta SO. Explica muy bien todos los métodos de empaquetado y podría ayudar a responder a 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 funciones. Presenta el paquete Python distutils que se puede importar en su script setup.py.

Herramientas de configuración 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 de Python setuptools que se puede importar en su secuencia de comandos setup.py, y el paquete de Python pkg_resources 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 paquete distutils de Python. 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 deben 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, en pocas palabras, 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 molesto y conlleva bastantes problemas, por ejemplo, incompatibilidades, lo que luego 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 herramientas de configuración, sin embargo, tenga en cuenta que sin distutils, las herramientas de configuración nunca habrían 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 del 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

Entonces NumPy prefiere setuptools si puede encontrarlo. Pero entonces SciPy solía hacer esto, hasta que fue parcheado 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, un fusión Entre setuptools y distribute debería resolver todo esto a su debido tiempo, pero muchos paquetes aún necesitan ser compatibles con 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 crear 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 admitir versiones anteriores de python o si se encuentra trabajando en un entorno desconocido.

En segundo lugar, setuptools proporciona mejoras a distutils. Por lo tanto, sigue el modelo del conjunto de herramientas distutils y toma toda su estructura de 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 setuptools mejora ese dialecto.

Mi enfoque personal para nuevos proyectos es comenzar con la suposición de que voy a usar distutils. Solo a medida que el proyecto crece y requiere una característica de las herramientas de configuración, realizo la actualización. Las herramientas de configuración son un reemplazo directo para distutils, es un cambio de una línea en mi setup.py.

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

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

• no está cubierto por el conjunto de pruebas principal y no depende de la funcionalidad central
• no lo hace sí mismo establecer estándares básicos para módulos complementarios (su ubicación, medios de importación, interfaz binaria de extensiones C, etc.).
• se actualiza y lanza independientemente de las versiones de Python

Efectivamente, el equipo central ha reducido el alcance de distutilsreservando las partes de “estándares básicos” y “compilación mínima necesaria” para ellos mismos dejando todas las cosas 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 para la compatibilidad con versiones anteriores.

De Distribución de módulos de Python — documentación de Python – 2.7.12:

Mientras que el uso directo de distutils se está eliminando gradualmente, todavía 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 utilizada para coordinar Python desarrollo de estándares de empaque).

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

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