setuptools vs distutils: pourquoi les distutils sont-ils encore une chose?

Python a une histoire confusion des outils qui peuvent être utilisés pour emballer et décrire les projets: ceux - ci sont distutilsdans la bibliothèque standard, distribute, distutils2et setuptools(et peut - être plus). Il semble que distributeet distutils2ont été abandonnés en faveur de setuptools, ce qui laisse deux normes concurrentes.

À ma connaissance, il setuptoolsoffre beaucoup plus d'options (par exemple, déclarer des dépendances, des tests, etc.) que distutils, cependant, il n'est pas inclus dans la bibliothèque standard Python (encore?).

Le guide de l'utilisateur de Python Packaging [ 1 ] recommande maintenant:

Permet setuptoolsde définir des projets et de créer des distributions source.

Et explique:

Bien que vous puissiez utiliser pure distutilspour de nombreux projets, il ne prend pas en charge la définition de dépendances sur d’autres projets et il manque plusieurs utilitaires pratiques permettant de remplir automatiquement correctement les métadonnées de package fournies par setuptools. En dehors de la bibliothèque standard, setuptools offre également un ensemble de fonctionnalités plus cohérent dans différentes versions de Python, et (contrairement à distutils),setuptools sera mis à jour pour produire les prochains formats standard «Metadata 2.0» sur toutes les versions prises en charge.

Même pour les projets qui choisissent d'utiliser distutils, lorsque pip installe ces projets directement à partir de la source (plutôt que d'installer à partir d'un fichier de roue prédéfini), il construira en fait votre projet à la setuptoolsplace.

Cependant, l' examen des fichiers setup.py de divers projets révèle que cela ne semble pas être une norme réelle. De nombreux packages utilisent encore distutilset ceux qui prennent en charge setuptoolsse mélangent souvent setuptoolsavec, distutilspar exemple en effectuant une importation de secours:

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

Suivi d'une tentative pour trouver un moyen d'écrire une configuration pouvant être installée à la fois par setuptoolset distutils. Cela inclut souvent diverses méthodes de vérification des dépendances sujettes aux erreurs, car distutilsne prend pas en charge les dépendances dans la fonction de configuration.

Pourquoi les gens font-ils encore des efforts supplémentaires pour soutenir distutils- le fait que ce setuptoolsne soit pas dans la bibliothèque standard est-il la seule raison? Quels sont les avantages distutilset y a-t-il des inconvénients à écrire des fichiers setup.py qui ne prennent en charge que setuptools.

Jetez un œil à cette question SO. Il explique très bien toutes les méthodes d'emballage et pourrait aider à répondre à votre question dans une certaine mesure: les différences entre distribuer, distutils, setuptools et distutils2?

Distutils est toujours l'outil standard pour l'empaquetage en Python. Il est inclus dans la bibliothèque standard (Python 2 et Python 3.0 à 3.3). Il est utile pour les distributions Python simples, mais manque de fonctionnalités. Il présente le package Python distutils qui peut être importé dans votre script setup.py.

Setuptools a été développé pour surmonter les limitations de Distutils et n'est pas inclus dans la bibliothèque standard. Il a introduit un utilitaire de ligne de commande appelé easy_install. Il a également introduit le package Python setuptools qui peut être importé dans votre script setup.py, et le package Python pkg_resources qui peut être importé dans votre code pour localiser les fichiers de données installés avec une distribution. L'un de ses pièges est qu'il monkey-patches le paquet Python distutils. Cela devrait bien fonctionner avec pip. La dernière version est sortie en juillet 2013.

Donc, comme vous pouvez le voir, setuptools devrait être préféré aux distutils, et je vois d'où vient votre question, mais je ne vois pas distutils perdre son support de sitôt, car, en termes simples, il est utilisé dans de nombreux cas avec certains programmes hérités populaires . Et comme vous le savez probablement, changer ce genre de choses dans les programmes hérités peut être assez pénible et entraîner de nombreux problèmes, par exemple des incompatibilités, ce qui obligerait alors le développeur à réécrire le code source. Il y a donc cela, et aussi le fait que distutils fait partie de la bibliothèque python standard alors que setuptools ne l'est pas. Donc, si vous créez un programme python, à notre époque, utilisez setuptools, mais gardez à l'esprit que sans distutils, setuptools n'aurait jamais existé.

est le fait que setuptools ne soit pas dans la bibliothèque standard la seule raison

C'est une des raisons. Ce qui suit provient directement du 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

Donc NumPy préfère setuptoolss'il peut le trouver. Mais ensuite, SciPy faisait cela, jusqu'à ce qu'il soit corrigé pour préférer distutilsdans certaines situations. Citant le journal de validation:

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

Bien sûr, une fusion entre setuptoolset distributedevrait résoudre tout cela en temps voulu, mais de nombreux paquets doivent encore prendre en charge les installations de Python 2.6.

Il y a plusieurs raisons dont nous parlons et utilisons encore distutils, même si setuptools est sans aucun doute le meilleur ensemble d'outils.

Premièrement, distutils est disponible partout. Si vous cherchez à créer un module pour le partager avec d'autres et que vous n'avez pas d'exigences compliquées, il est garanti qu'il sera disponible sur votre machine de travail. Ceci est particulièrement important si vous devez prendre en charge des versions plus anciennes de python, ou si vous travaillez dans un environnement inconnu.

Deuxièmement, setuptools apporte des améliorations aux distutils. Il est donc modélisé d'après le jeu d'outils distutils et prend toute sa structure à partir de là. La documentation de setuptools suppose que le lecteur est familiarisé avec distutils et ne documente que la manière dont il améliore le jeu d'outils de base. Vous pouvez penser que distutils définit le dialecte et setuptools améliore ce dialecte.

Mon approche personnelle pour les nouveaux projets est de commencer par l'hypothèse que je vais utiliser distutils. Ce n'est qu'au fur et à mesure que le projet grandit et nécessite une fonctionnalité de setuptools que je procède à la mise à niveau. Le setuptools est un remplacement direct pour distutils, c'est un changement d'une ligne à mon setup.py.

Fondamentalement, c'est dû à la division des responsabilités.

setuptoolsne fait pas partie de la bibliothèque standard Python car elle est maintenue par une tierce partie plutôt que par l'équipe principale de Python. Ce qui signifie, entre autres:

• il n'est pas couvert par la suite de tests de base et n'est pas utilisé par les fonctionnalités de base
• il ne définit pas lui-même les normes de base pour les modules complémentaires (leur emplacement, les moyens d'importation, l'interface binaire des extensions C, etc.).
• il est mis à jour et publié indépendamment des versions de Python

Effectivement, l'équipe de base a réduit la portée des distutils , se réservant les parties "standards de base" et "compilation minimale nécessaire" tout en laissant tout le reste (compilateur étendu / format de package / quel que soit le support) à des tiers. Le code qui couvrait auparavant ces "parties étendues" est resté périmé pour des raisons de compatibilité ascendante.

From Distributing Python Modules - Documentation Python 2.7.12 :

Bien que l'utilisation directe de distutilssoit progressivement supprimée, elle a toujours jeté les bases de l'infrastructure actuelle de conditionnement et de distribution, et elle reste non seulement une partie de la bibliothèque standard, mais son nom perdure d'autres manières (comme le nom de la liste de diffusion utilisé pour coordonner le développement des normes d'emballage Python).

Les packages pour d'autres systèmes d'exploitation sont également susceptibles de fournir setuptoolset pipséparément - pour les raisons susmentionnées

• et parce qu'ils ne sont pas nécessaires - ou sont même préjudiciables à la maintenabilité - alors qu'il y a déjà un autre gestionnaire de paquets sur le système.