2009-10-13 6 views
11

Normalerweise tendiere ich dazu, Dinge über den Paket-Manager zu installieren, für Unix-Sachen. Allerdings, wenn ich viel Perl programmiert habe, würde ich CPAN, neuere Versionen und all das verwenden.Welches ist das pythonischste: die Installation von Python-Modulen über einen Paket-Manager (Macports, apt) oder über pip/easy_install/setuptools

Im Allgemeinen habe ich Sytemdateien über Paket-Manager und Sprach Sachen über einen eigenen Paketmanager installieren (gem/easy_install | pip/cpan)

Jetzt mit Python in erster Linie, ich frage mich, was das Beste Praxis ist ?

Antwort

17

Die System-Python-Version und ihre Bibliotheken werden oft von Software in der Distribution verwendet. Solange die Software, die Sie verwenden, mit den gleichen Versionen von Python und allen Bibliotheken Ihrer Distribution zufrieden ist, funktioniert die Verwendung der Distributionspakete problemlos.

Oft benötigen Sie jedoch Entwicklungsversion von Paketen oder neuere Version oder ältere Versionen. Und dann funktioniert es nicht mehr.

Daher wird normalerweise empfohlen, eine eigene Python-Version für die Entwicklung zu installieren und Entwicklungsumgebungen mit buildout oder virtualenv oder beiden zu erstellen, um das System Python und die Entwicklungsumgebung voneinander zu isolieren.

+1

[Pyenv] (https://github.com/yyuu/pyenv#readme) ist ein wunderbares Werkzeug zum Verwalten mehrerer Python-Versionen und [virtualenvs] (https://github.com/yyuu/pyenv-virtualenv#readme). –

17

Es gibt zwei komplett gegensätzliche Lager: eines zugunsten von System-Paketen und eines für separate Installation. Ich bin persönlich im "System-Paket" -Camp. Ich werde Argumente von jeder Seite unten zur Verfügung stellen.

Pro Systempakete: Der Systempacker kümmert sich bereits um die Abhängigkeit und die Einhaltung der Gesamtsystemrichtlinien (z. B. Dateilayout). Systempakete stellen Sicherheitsupdates bereit, während sie immer noch darauf achten, die Kompatibilität nicht zu beeinträchtigen - daher werden manchmal Sicherheitsupdates zurückportiert, die die Autoren des Upstream nicht zurückportiert haben. Systempakete sind "sicher". System-Upgrades: Nach einem System-Upgrade haben Sie wahrscheinlich auch eine neue Python-Version, aber alle Ihre Python-Module sind noch vorhanden, wenn sie von einem System-Packager stammen. Das ist alles persönliche Erfahrung mit Debian.

Con Systempakete: Nicht alle Software kann als Systempaket zur Verfügung gestellt werden oder nicht in der neuesten Version; Wenn Sie sich selbst in das System installieren, können Systempakete beschädigt werden. Upgrades können Ihre Anwendung beschädigen.

Pro separate Installation: Einige Leute (insbesondere Web-Anwendung Entwickler) argumentieren, dass Sie unbedingt eine wiederholbare Installation benötigen, nur mit den Paketen, die Sie wollen, und vollständig von System Python entkoppelt. Dies geht über Self-Installed vs. System-Pakete hinaus, da Sie selbst bei einer selbst installierten Version möglicherweise noch das System Python modifizieren; Mit der separaten Installation werden Sie nicht. Wie Lennart erläutert, gibt es jetzt spezielle Toolketten, die diese Einrichtung unterstützen. Die Leute argumentieren, dass nur dieser Ansatz wiederholbare Ergebnisse garantieren kann.

Con getrennte Installation: Sie müssen sich selbst mit Fehlerbehebungen befassen, und Sie müssen sicherstellen, dass alle Benutzer die separate Installation verwenden. Im Fall von Web-Anwendungen ist Letzteres typischerweise einfach zu erreichen.

+0

Fair genug. Ich frage mich immer, warum setuptools und vor allem rubygems et al nicht in/usr/local tree installiert werden, wo es Dinge gibt, die lokal sind. Ah, gut. Für das, was es wert ist, ein Systemadministrator zu sein (sind wir nicht alle viele Dinge?), Bevorzuge ich Ihren Ansatz. Scheint aber mit Python ziemlich problematisch zu sein.Halten Sie meine Nase und gehen Sie die "Entwicklungsumgebung Route" – chiggsy

+1

Ich stimme voll und ganz zu, dass Distro-Pakete vorzuziehen sind, wenn Sie im System Python installieren. Aber für die Entwicklungsarbeit und auch für ein Produktionssystem, das viel leistet, werden Sie separate Umgebungen für separate Software benötigen (es sei denn, sie alle sind als aktualisierte und beibehaltene Distributionspakete verfügbar). –

+0

Als persönliche Richtlinie verzichte ich auf die Verwendung von Software, für die kein Systempaket vorhanden ist, oder auf eine andere Version als die, die der Systempacker bereitstellt. Dies kann bedeuten, dass ich nicht viele Pakete verwenden kann - viel Glück; Ich werde vielleicht Sachen neu implementieren müssen. Auf der positiven Seite, ich bin beschränkt auf die Verwendung von "Stable" -Software, so dass ich nicht wirklich jede Entwicklungsversion verfolgen muss, nur weil einige Bibliothek entscheidet, dass es eine unveröffentlichte Version eines anderen Pakets benötigt. –

Verwandte Themen