Différences entre distribuer, distutils, setuptools et distutils2?
La situation
J'essaie de porter une bibliothèque open-source sur Python 3. ( SymPy , si quelqu'un se le demande.)
Donc, je dois exécuter 2to3 automatiquement lors de la compilation pour Python 3. Pour ce faire, je dois utiliser distribute. Par conséquent, je dois porter le système actuel, qui (selon le doctest) est distutils.
Le problème
Malheureusement, je ne sais pas quelle est la différence entre ces modules —distutils, distribute, setuptools. La documentation est au mieux fragmentaire, car ils semblent tous être une fourchette les uns des autres, destinés à être compatibles dans la plupart des circonstances (mais en réalité, pas tous)… et ainsi de suite.
La question
Quelqu'un pourrait-il expliquer les différences? Qu'est-ce que je suis censé utiliser? Quelle est la solution la plus moderne? (En passant, j’apprécierais également des conseils sur le portage de Distribute, mais c’est un peu au-delà de la portée de la question…)
Je suis un mainteneur de distutils et un contributeur de distutils2/packaging. J’ai fait un exposé sur le packaging de Python lors de ConFoo 2011 et ces derniers temps, j’en écris une version étendue. Il n’a pas encore été publié. Voici donc des extraits qui devraient aider à définir les choses.
Distutils est l’outil standard utilisé pour l’emballage. Cela fonctionne plutôt bien pour des besoins simples, mais est limité et facile à étendre.
Setuptools est un projet né du désir de compléter les fonctionnalités de distutils manquantes et d'explorer de nouvelles directions. Dans certaines sous-communautés, il s’agit d’un standard de facto . Il utilise la magie et les correctifs de singe désapprouvés par Python principaux développeurs.
Distribute est une fourchette de Setuptools qui a été créée par les développeurs qui ont le sentiment que son rythme de développement était trop lent et qu'il n'était pas possible de le faire évoluer. Son développement a été considérablement ralenti lorsque distutils2 a été lancé par le même groupe. Mise à jour 2013-août: la distribution est fusionnée dans setuptools et abandonnée.
Distutils2 est une nouvelle bibliothèque distutils, démarrée comme un fork du code base de distutils, avec de bonnes idées extraites d'outils de configuration (dont certaines ont été examinées de manière approfondie dans PEP ) et un installateur basique inspiré de pip.
Le nom que vous utilisez pour importer Distutils2 estDistutils2 n'a pas publié la version Python 3.3 et a été mis en attente.packagingdans la bibliothèque standard Python 3.3+ oudistutils2dans les versions 2.4+ et 3.1–3.2. (Un backport sera bientôt disponible.)
Plus d'informations:
- Le destin de Distutils - Rapport détaillé de Pycon Summit + Packaging Sprint
- n rapide différentiel entre Distutils et Distutils2
J’espère terminer mon guide bientôt. Il contiendra plus d’informations sur les points forts et les points faibles de chaque bibliothèque et un guide de transition.
REMARQUE: Réponse obsolète, distribuer maintenant obsolète.
Oui, vous l'avez. : -o Je pense qu'actuellement le paquet préféré est Distribuer , qui est un fork de setuptools, qui est une extension de distutils (le système de packaging d'origine). Setuptools n’était pas mis à jour, il a donc été modifié et renommé. Toutefois, lorsqu’il est installé, il utilise le nom du paquet setuptools! Je pense que la plupart des Python développeurs utilisent maintenant Distribute, et je peux affirmer que oui.
Beaucoup de gens se sont plaints ici du manque de conseils clairs de la communauté sur cette question.
Actuellement, cela ressemble à la meilleure source faisant autorité sur les recommandations d’outils: https://packaging.python.org/en/latest/current.html#tool-recommendations
La mise à jour de cette question à la fin de 2014, où heureusement le chaos de l'emballage Python a été grandement nettoyée par le gestionnaire de paquets " conda " de Continuum.
En particulier, conda permet rapidement la création de conda " environnements ". Vous pouvez configurer vos environnements avec différentes versions de Python. Par exemple:
conda create -n py34 python=3.4 anaconda
conda create -n py26 python=2.6 anaconda
créera deux environnements ("py34" ou "py26") Python avec des versions différentes de Python.
Ensuite, vous pouvez appeler l'environnement avec la version spécifique de Python avec:
source activate <env name>
Cette fonctionnalité semble particulièrement utile dans le cas où vous devez traiter différentes versions de Python.
De plus, conda présente les caractéristiques suivantes:
- Agnostique python
- Plateforme croisée
- Aucun privilège administrateur requis
- Gestion intelligente des dépendances (à l'aide d'un solveur SAT)
- Traite bien les bibliothèques C, Fortran et système que vous pouvez avoir à lier contre
Ce dernier point est particulièrement important si vous êtes dans l'arène de l'informatique scientifique.
Je me rends compte que j'ai répondu à votre question secondaire sans aborder les hypothèses incontestées de votre problème initial:
J'essaie de porter une bibliothèque open-source (SymPy, si quelqu'un le souhaite) sur Python 3. Pour ce faire, je dois exécuter 2to3 automatiquement lors de la construction de Python 3 .
Vous pouvez , pas avoir besoin . D'autres stratégies sont décrites à http://docs.python.org/dev/howto/pyporting
Pour ce faire, je dois utiliser distribuer,
Vous pouvez :) distutils prend en charge la conversion 2to3 au moment de la construction pour le code (et non les docstrings), d'une manière différente de celle qui distribue: http://docs.python.org/dev/howto/pyporting#during-installation
Ce sujet semble être toujours en pleine mutation. Le "Guide de l'utilisateur de l'emballage Python" Quick Recommendations définit "le jeu d'outils actuellement recommandé". C'était un lien vers "L'avenir de Python Packaging" qui est maintenant, 1/20/2019, 5+ ans plus tard, un lien mort. :)