Setuptools vs. distutils: Warum ist distutils noch etwas?

Python hat eine verwirrende Geschichte von Werkzeugen, die verwendet werden können, um Projekte zu verpacken und zu beschreiben: Dazu gehören distutils in der Standardbibliothek, verteilen , distutils2 und setuptools und vielleicht mehr. Es scheint, dass verteilte und distutils2 zugunsten von setuptools , die zwei konkurrierende Standards verlässt, abgesetzt wurden.

Zu meinem Verständnis bietet setuptools weit mehr Optionen (zB Deklaration von Abhängigkeiten, Tests etc.) als distutils , aber es ist nicht in der Python-Standardbibliothek (noch?) Enthalten.

Das Python Packaging Benutzerhandbuch [ 1 ] empfiehlt jetzt:

Verwenden Sie setuptools, um Projekte zu definieren und Source Distributionen zu erstellen.

Und erklärt:

Obwohl Sie reine distutils für viele Projekte verwenden können, unterstützt es nicht, Abhängigkeiten von anderen Projekten zu definieren und fehlt mehrere Convenience-Dienstprogramme, um automatisch Paket-Metadaten korrekt zu pflanzen, die von setuptools bereitgestellt werden. Außerhalb der Standardbibliothek bietet setuptools auch ein konsistentes Feature, das über verschiedene Versionen von Python eingestellt ist, und (im Gegensatz zu> distutils) werden setuptools aktualisiert, um die anstehenden "Metadata 2.0" Standardformate auf allen unterstützten Versionen zu produzieren.

Auch für Projekte, die sich für die Verwendung von distutils entscheiden, wenn Pip solche Projekte direkt aus der Quelle installieren (anstatt von einer vorgefertigten Raddatei zu installieren), wird es tatsächlich Ihr Projekt mit Setuptools erstellen.

Allerdings zeigt das Schauen in verschiedene Projekt's setup.py Dateien zeigt, dass dies nicht zu einem tatsächlichen Standard zu sein scheint. Viele Pakete verwenden immer noch distutils und diejenigen, die Setup- Tools unterstützen, mischen oft Setuptools mit distutils zB durch einen Fallback-Import:

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

Gefolgt von einem Versuch, einen Weg zu finden, um ein Setup zu schreiben, das sowohl von setuptools als auch von distutils installiert werden kann . Dies beinhaltet oft verschiedene Möglichkeiten der fehleranfälligen Abhängigkeitsprüfung, da distutils keine Abhängigkeiten in der Setup-Funktion unterstützt.

Warum sind die Leute immer noch die zusätzlichen Anstrengungen, um distutils zu unterstützen – ist die Tatsache, dass setuptools nicht in der Standardbibliothek der einzige Grund ist? Was sind die Vorteile von distutils und gibt es irgendwelche Nachteile des Schreibens setup.py Dateien, die nur setuptools unterstützen .

    4 Solutions collect form web for “Setuptools vs. distutils: Warum ist distutils noch etwas?”

    Schau dir das an. Es erklärt alle Verpackungsmethoden sehr gut und könnte helfen, Ihre Frage zu einem gewissen Grad zu beantworten: Webseite

    Distutils ist immer noch das Standardwerkzeug für die Verpackung in Python. Es ist in der Standardbibliothek enthalten (Python 2 und Python 3.0 bis 3.3). Es ist nützlich für einfache Python-Distributionen, aber fehlt Features. Es stellt das Distutils-Python-Paket vor, das in deinem setup.py-Skript importiert werden kann.

    Setuptools wurde entwickelt, um die Grenzen von Distutils zu überwinden und ist nicht in der Standardbibliothek enthalten. Es hat ein Befehlszeilenprogramm namens easy_install eingeführt. Es hat auch das setuptools Python-Paket eingeführt, das in deinem setup.py-Skript importiert werden kann und das pkg_resources Python-Paket, das in deinem Code importiert werden kann, um mit einer Distribution installierte Datendateien zu lokalisieren. Einer seiner Gotchas ist, dass es Affen-Patches die distutils Python-Paket. Es sollte gut mit Pip arbeiten. Die neueste Version wurde im Juli 2013 veröffentlicht.

    Also, wie Sie sehen können, dass setuptools auf distutils vorbereitet werden sollte, und ich sehe, woher Ihre Frage kommt, aber ich sehe nicht, dass distutils die Unterstützung jederzeit bald verlieren wird, wie es einfach gesagt wird, es ist in vielen Fällen (vor allem Legacy-Programme) Defacto standard Und wie Sie wahrscheinlich wissen, ändern diese Art von Sachen in Legacy-Programme kann ein ganzer Schmerz sein und kommen mit ein paar Probleme, zum Beispiel Inkompatibilitäten, die dann dazu führen würde, dass der Entwickler den Quellcode umschreiben muss. So gibt es das, und auch die Tatsache, dass distutils ist ein Teil der Standard-Python-Bibliothek, während Setuptools ist nicht. Also, wenn Sie ein Python-Programm erstellen, in diesem Tag und Alter, verwenden Sie setuptools, aber denken Sie daran, dass ohne distutils, setuptools nie existiert hätte.

    Es gibt mehrere Gründe, von denen wir noch reden und distutils verwenden, obwohl setuptools ohne Zweifel das bessere Werkzeugset ist.

    Erstens ist überall distutils vorhanden. Wenn Sie schauen, um ein Modul für den Austausch mit anderen zu bauen, und haben keine komplizierten Anforderungen, ist es garantiert auf Ihrer Arbeitsmaschine zur Verfügung stehen. Dies ist besonders wichtig, wenn Sie ältere Versionen von Python unterstützen müssen oder wenn Sie sich in einer fremden Umgebung befinden.

    Zweitens bietet setuptools Verbesserungen für distutils. Es ist also nach dem distutils-Werkzeugsatz modelliert und nimmt von dort aus die Struktur. Die Dokumentation für setuptools geht davon aus, dass der Leser mit distutils vertraut ist und nur Dokumente dokumentiert, wie es das Basiswerkzeugset verbessert Sie können daran denken, dass distutils den Dialekt definiert und setuptools diesen Dialekt verstärkt.

    Mein persönlicher Ansatz für neue Projekte beginnt mit der Annahme, dass ich Distutils verwenden werde. Nur als das Projekt wächst, um eine Funktion von setuptools erfordern, mache ich das Upgrade. Die setuptools ist ein Drop-in-Ersatz für distutils, es ist eine einzeilige Änderung an meinem setup.py.

    Ist die Tatsache, dass setuptools nicht in der Standardbibliothek der einzige Grund ist

    Das ist ein grund Das folgende ist direkt aus dem 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 

    Also NumPy bevorzugt setuptools wenn es es finden kann. Aber dann hat SciPy das getan, bis es in einigen Situationen distutils wurde, distutils zu bevorzugen. Aufruf des Commit-Protokolls:

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

    Natürlich muss eine Fusion zwischen setuptools und distribute dies alles rechtzeitig lösen, aber viele Pakete müssen noch Python 2.6 Installationen unterstützen.

    Grundsätzlich liegt es an der Aufteilung der Verantwortlichkeiten.

    setuptools ist nicht ein Teil der Python-Standardbibliothek, weil es von einem Drittanbieter statt Python-Kernteam gepflegt wird. Das bedeutet unter anderem:

    • Es wird nicht von der Kern-Test-Suite abgedeckt und wird nicht durch Kernfunktionalität verlassen
    • Es setzt sich nicht selbst Kernvorgaben für Add-on-Module (deren Standort, Importmittel, C-Erweiterungen 'binäre Schnittstelle etc.).
    • Es ist aktualisiert und veröffentlicht unabhängig von Python Releases

    In Wirklichkeit hat das Kernteam den Umfang der distutils verkleinert , indem er die "Kernstandards" und "minimal notwendige Kompilierung" Teile für sich selbst reserviert hat, während er alle Sachen hinter sich hat (verlängerter Compiler / Paketformat / was auch immer Unterstützung) an Dritte. Der Code, der vorher diese "ausgedehnten Teile" abdeckte, wurde für Rückwärtskompatibilität veraltet .

    Von der Verteilung von Python-Modulen – Python 2.7.12 Dokumentation :

    Während die direkte Nutzung von distutils auslaufen wird, legte sie immer noch die Grundlage für die aktuelle Verpackungs- und Verteilungsinfrastruktur, und sie bleibt nicht nur Teil der Standardbibliothek, sondern ihr Name lebt auf andere Weise (wie der Name des Mailings) Liste zur Koordinierung der Python-Verpackungsstandards Entwicklung).

    Pakete für andere Betriebssysteme sind ebenfalls setuptools , setuptools und pip separat zur Verfügung zu stellen – aus den vorgenannten Gründen

    • Und weil sie nicht notwendig sind – oder sogar nachteilig für die Wartbarkeit sind -, wenn es bereits einen anderen Paketmanager auf dem System gibt.
    Python ist die beste Programmiersprache der Welt.