web-dev-qa-db-fra.com

setuptools vs distutils: pourquoi le distutils est-il encore une chose?

Python a une histoire confuse d’outils pouvant être utilisés pour conditionner et décrire des projets: ceux-ci incluent distutils dans la bibliothèque standard, distribute, distutils2, et setuptools (et peut-être plus). Il semble que distribute et distutils2 ont été abandonnés au profit de setuptools, ce qui laisse deux normes en concurrence.

À ma connaissance, setuptools offre beaucoup plus d'options (par exemple, la déclaration de dépendances, de tests, etc.) que distutils, mais il n'est pas inclus dans la Python (encore?).

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

Utilisez setuptools pour définir des projets et créer des distributions source.

Et explique:

Bien que vous puissiez utiliser purement distutils pour 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 pour remplir automatiquement les métadonnées de package fournies par setuptools. Etant en dehors de la bibliothèque standard, setuptools offre également un ensemble de fonctionnalités plus cohérent à travers 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 des sources (plutôt que depuis un fichier de roue prédéfini), il construira votre projet en utilisant setuptools à la place.

Cependant, l'examen de divers fichiers de projet setup.py révèle que cela ne semble pas être une norme réelle. De nombreux paquets utilisent encore distutils et ceux qui prennent en charge setuptools mélangent souvent setuptools avec distutils, par exemple. en effectuant une importation de secours:

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

Suivi d'une tentative de trouver un moyen d'écrire une configuration pouvant être installée à la fois par setuptools et distutils. Cela inclut souvent différentes méthodes de vérification de dépendance sujettes aux erreurs, puisque distutils ne 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 setuptools ne se trouve pas dans la bibliothèque standard en est la seule raison? Quels sont les avantages de distutils et existe-t-il des inconvénients à l'écriture des fichiers setup.py ne prenant en charge que setuptools.

pythonpackagingsetuptoolsdistutils
126
cel

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

Distutils est toujours l'outil standard pour le packaging en Python. Il est inclus dans la bibliothèque standard (Python 2 et Python 3,0 à 3,3). Il est utile pour les distributions simples Python, mais il manque des fonctionnalités. Il introduit la distutils Python pouvant être importé dans votre script setup.py.

Setuptools a été développé pour surmonter les limites 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 paquet setuptools Python pouvant être importé dans votre script setup.py et le paquet pkg_resources Python pouvant être importé dans votre code pour localiser fichiers de données installés avec une distribution. L’un de ses pièges est qu’il corrige le paquet distutils Python. Il devrait bien fonctionner avec pip. La dernière version a été publiée en juillet 2013.

Donc, comme vous pouvez le constater, setuptools devrait être préféré à distutils, et je vois d'où vient votre question. Cependant, je ne vois pas que distutils perde de l'aide de si tôt, car, tout simplement, il est utilisé dans de nombreux programmes classiques . Et comme vous le savez probablement, modifier ce type de choses dans les programmes existants peut s'avérer très pénible et présenter de nombreux problèmes, par exemple des incompatibilités, ce qui obligerait alors le développeur à réécrire le code source. Donc, il y a cela, et aussi le fait que distutils fait partie de la bibliothèque standard python alors que setuptools ne l'est pas. Donc, si vous créez un python programme, de nos jours, utilise setuptools, mais gardez à l’esprit que sans distutils, setuptools n’aurait jamais existé.

70
user3429036

est le fait que setuptools n'est pas dans la bibliothèque standard la seule raison

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

Donc NumPy préfère setuptools s'il peut le trouver. Mais alors, SciPy faisait cela jusqu’à ce que corrigé préférer distutils dans certaines situations. Citer le journal de commit:

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

Bien sûr, un fusion entre setuptools et distribute devrait résoudre tout cela en temps voulu, mais de nombreux paquets doivent toujours supporter Python = 2.6 installations.

11
Fred Foo

Nous utilisons toujours distutils pour plusieurs raisons, même si setuptools est sans aucun doute le meilleur jeu d’outils.

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

Deuxièmement, setuptools fournit des améliorations à distutils. Il est donc calqué sur le jeu d’outils distutils et reprend 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 l'ensemble des outils de base. Vous pouvez penser que distutils définit le dialecte et que setuptools l’améliore.

Mon approche personnelle pour les nouveaux projets commence avec l’idée que je vais utiliser distutils. Je fais la mise à niveau uniquement lorsque le projet nécessite une fonctionnalité de setuptools. Le setuptools est un remplacement instantané pour distutils, c'est un changement d'une ligne à mon setup.py.

9
user590028

En gros, cela est dû à la division des responsabilités.

setuptools ne fait pas partie de la bibliothèque standard de Python car elle est gérée par une tierce partie plutôt que Python. Ce qui signifie, entre autres des choses:

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

Effectivement, l’équipe principale a restreint la portée des distutils , en réservant les parties "normes de base" et "compilation minimale nécessaire" en laissant tout ce qui va au-delà (compilateur étendu/format de package/quel que soit le support) à une tierce partie. Le code qui couvrait auparavant ces "parties étendues" a été laissé périmé pour des raisons de compatibilité ascendante.

De Distribution Python Modules - Python 2.7.12) :

Bien que l’utilisation directe de distutils soit en train de disparaître, elle jette toujours les bases de l’infrastructure actuelle de conditionnement et de distribution, et non seulement elle fait partie de la bibliothèque standard, mais son nom subsiste d’autres manières (comme le nom de la liste de diffusion utilisée pour coordonner Python développement de normes de conditionnement).

Les packages pour d’autres systèmes d’exploitation sont également susceptibles de fournir setuptools et pip séparément - pour les raisons susmentionnées

  • et parce qu'ils ne sont pas nécessaires - ou sont même préjudiciables à la facilité de maintenance - lorsqu'il existe déjà un autre gestionnaire de paquets sur le système.
7
ivan_pozdeev