Python-Pakete werden häufig in den Repositorys vieler Distributionen gehostet. Nach dem Lesen dieses Lernprogramms, insbesondere des Abschnitts mit dem Titel "Wollen Sie das wirklich tun?", Habe ich die Verwendung von pip vermieden und es vorgezogen, das System-Repository zu verwenden. Ich habe nur dann auf pip zurückgegriffen, wenn ich ein Paket installieren muss, das sich nicht im Repository befindet.

Wäre es jedoch besser, nur pip zu verwenden, da dies eine inkonsistente Installationsmethode ist? Was sind die Vorteile / Nachteile der Verwendung von pip über das systemeigene Repository für Pakete, die an beiden Orten verfügbar sind?

Der Link, den ich eingeschlossen habe, besagt

Der Vorteil, immer Standard-Debian / NeuroDebian-Pakete zu verwenden, besteht darin, dass die Pakete sorgfältig getestet wurden, um kompatibel zu sein. Die Debian-Pakete zeichnen Abhängigkeiten mit anderen Bibliotheken auf, so dass Sie immer die Bibliotheken erhalten, die Sie als Teil der Installation benötigen.

Ich benutze Bogen. Ist dies bei anderen Paketverwaltungssystemen als apt der Fall?

Der größte Nachteil, den ich bei pipder Installation von Python-Modulen auf Ihrem System sehe , sei es als Systemmodul oder als Benutzermodul, ist, dass das Paketverwaltungssystem Ihrer Distribution nichts davon weiß. Dies bedeutet, dass sie nicht für andere Pakete verwendet werden, die sie benötigen und die Sie möglicherweise in Zukunft installieren möchten (oder die nach einem Upgrade möglicherweise eines dieser Module verwenden). Sie erhalten dann sowohl eine pipvon der Distribution verwaltete als auch eine von der Distribution verwaltete Version der Module, was zu Problemen führen kann (ich bin kürzlich auf eine weitere Instanz davon gestoßen). Ihre Frage ist also ein Alles-oder-Nichts-Vorschlag: Wenn Sie nur verwendenpip Für Python-Module können Sie den Paket-Manager Ihrer Distribution nicht mehr für alles verwenden, was ein Python-Modul verwenden möchte ...

Der allgemeine Rat auf der Seite, auf die Sie verlinkt haben, ist sehr gut: Versuchen Sie, die Pakete Ihrer Distribution so weit wie möglich zu verwenden pip, und verwenden Sie sie nur für Module, die nicht gepackt sind. breit. Verwenden Sie möglichst virtuelle Umgebungen, insbesondere für die Modulentwicklung. Insbesondere auf Arch sollten Sie nicht auf Probleme stoßen, die durch ältere Module verursacht wurden. Selbst bei Distributionen, bei denen dies problematisch sein kann, können virtuelle Umgebungen problemlos damit umgehen.

Es ist immer zu bedenken, dass die Bibliotheks- und Modulpakete einer Distribution in erster Linie für die Verwendung anderer Pakete in der Distribution gepackt werden. Sie zu haben ist ein netter Nebeneffekt für die Entwicklung mit diesen Bibliotheken und Modulen, aber das ist nicht der primäre Anwendungsfall.

TL; DR

• benutze pip(+ virtualenv) für Dinge (libs, frameworks, vielleicht dev tools) , die du in deinen Projekten (die du entwickelst) verwendest
• Verwenden Sie den Paket-Manager für Anwendungen, die Sie verwenden (als Endbenutzer).

Entwicklungsabhängigkeiten

Wenn Sie Software in Python entwickeln, sollten Sie diese pipfür alle Abhängigkeiten des Projekts verwenden, seien es Laufzeitabhängigkeiten, Abhängigkeiten zur Erstellungszeit oder Dinge, die für automatisierte Tests und automatische Konformitätsprüfungen (Linter, Stilprüfprogramm, statische Typprüfung) erforderlich sind ...)

Dafür gibt es mehrere Gründe:

• Auf diese Weise können Sie virtualenv (entweder direkt oder über virtualenvwrapper oder pipenv oder auf andere Weise) verwenden, um Abhängigkeiten verschiedener Projekte voneinander zu trennen und die Python-Anwendungen, die Sie "in der Produktion" (als Benutzer) verwenden, von exotischen Spielereien (oder auch nur Inkompatibilitäten), die in der Entwicklung weitergehen können.
• Auf diese Weise können Sie alle Abhängigkeiten eines Projekts in einer Datei requirements.txt(wenn es sich bei Ihrem Projekt um eine Anwendung handelt) oder setup.py(wenn es sich bei Ihrem Projekt um eine Bibliothek oder ein Framework handelt) nachverfolgen. Dies kann zusammen mit dem Quellcode in die Versionskontrolle (z. B. Git) eingecheckt werden, sodass Sie immer wissen, welche Version Ihres Codes von welchen Versionen Ihrer Abhängigkeiten abhängt.
• Das Obige ermöglicht es anderen Entwicklern, an Ihrem Projekt zusammenzuarbeiten, auch wenn sie nicht dieselbe Linux-Distribution oder nicht dasselbe Betriebssystem verwenden (wenn die verwendeten Abhängigkeiten auch auf Mac und Windows verfügbar sind oder was auch immer sie gerade verwenden).
• Sie möchten nicht, dass automatische Updates des Paketmanagers Ihres Betriebssystems Ihren Code beschädigen. Sie sollten Ihre Abhängigkeiten aktualisieren, dies sollten Sie jedoch bewusst und zu bestimmten Zeitpunkten tun, damit Sie bereit sind, den Code zu korrigieren oder das Update zurückzusetzen. (Was einfach ist, wenn Sie die vollständige Abhängigkeitserklärung in Ihrem Revisionskontrollsystem zusammen mit Ihrem Code nachverfolgen.)

Wenn Sie der Meinung sind, dass Sie direkte und indirekte Abhängigkeiten trennen müssen (oder zwischen einem akzeptablen Versionsbereich für eine Abhängigkeit und der tatsächlich verwendeten Version unterscheiden müssen, siehe "Versions-Pinning"), schauen Sie in Pip-Tools und / oder Pipenv. Auf diese Weise können Sie auch zwischen Build- und Testabhängigkeiten unterscheiden. (Die Unterscheidung zwischen Build- und Laufzeitabhängigkeiten kann wahrscheinlich in codiert werden. setup.py)

Anwendungen, die Sie verwenden

Für Dinge, die Sie als normale Anwendung verwenden und die zufällig in Python geschrieben sind, ziehen Sie den Paketmanager Ihres Betriebssystems vor. Es stellt sicher, dass es auf dem neuesten Stand ist und mit anderen vom Paketmanager installierten Komponenten kompatibel ist. Die meisten Linux-Distributionen behaupten auch, dass sie keine Malware verbreiten.

Wenn etwas, das Sie benötigen, nicht im Standardpaketrepo Ihrer Distribution verfügbar ist, können Sie zusätzliche Paketrepos auschecken (z. B. Launchpad von deb-basierten Distributionen) oder es piptrotzdem verwenden. In letzterem Fall können Sie --userdie Installation nicht systemweit, sondern zu Hause beim Benutzer ausführen, sodass die Wahrscheinlichkeit geringer ist, dass die Python-Installation unterbrochen wird. (Für Dinge, die Sie nur vorübergehend oder selten benötigen, können Sie sogar eine virtuelle Umgebung verwenden.)

Ein weiterer Grund für den Paketmanager ist, dass Updates automatisch angewendet werden, was für die Sicherheit von entscheidender Bedeutung ist. Denken Sie, wenn das verwendete Beans-Paket Equifax über yum-cron-security automatisch aktualisiert wurde, ist der Hack möglicherweise nicht aufgetreten.

Auf meiner persönlichen Entwicklungsbox verwende ich Pip, in prod verwende ich Pakete.

Wenn wir über die Installation von Python-Paketen für den von Ihnen geschriebenen Code sprechen, verwenden Sie pip.

Erstellen Sie für jedes Projekt, an dem Sie arbeiten, eine virtuelle Umgebung, und installieren Sie dann nur die für das Projekt erforderlichen Elemente mit pip. Auf diese Weise installieren Sie alle von Ihnen verwendeten Bibliotheken auf konsistente Weise. Sie sind enthalten und beeinträchtigen nichts, was Sie über Ihren Paketmanager installieren.

Wenn Sie vorhaben, Python-Code zu veröffentlichen, fügen Sie in der Regel ein setup.pyoder requirements.txtzu Ihrem Projekt hinzu, damit pip automatisch alle Abhängigkeiten abrufen kann. So können Sie auf einfache Weise eine virtuelle Umgebung für dieses Projekt erstellen oder neu erstellen.

Zusammenfassung

Es gibt drei allgemeine Kategorien von Modulen, mit denen Sie es zu tun haben:

1. Diese unterstützenden Programme sind für alle Benutzer mit dem Betriebssystempaketsystem installiert. (Dies kann sogar Tools und Bibliotheken einschließen, die von Personen verwendet werden, die in Python programmieren. Siehe unten.) Für diese verwenden Sie die Betriebssystempakete, wo Sie können, und pipinstallieren sie bei Bedarf in den Systemverzeichnissen.
2. Diese unterstützenden Programme werden von einem bestimmten Benutzer nur für den eigenen Gebrauch und für bestimmte Aspekte ihrer "täglichen" Verwendung von Python als Skriptsprache installiert. Für diese verwendet sie pip --uservielleicht Pyenv oder Pythonz und ähnliche Werkzeuge und Taktiken.
3. Diejenigen, die die Entwicklung und Verwendung einer bestimmten Anwendung unterstützen. Für diese verwenden Sie virtualenv(oder ein ähnliches Tool).

Jede Ebene hier kann auch Unterstützung von einer vorherigen Ebene erhalten. Beispielsweise kann sich unser Benutzer in (2) auf einen Python-Interpreter verlassen, der über Betriebssystempakete installiert wird.

Darauf gehen wir etwas genauer ein:

Systemprogramme und Pakete

In Python geschriebene Programme, die Sie "nur ausführen" möchten, sind einfach: Verwenden Sie einfach die OS-Installationstools und lassen Sie sie alles einspielen, was sie benötigen. Dies unterscheidet sich nicht von einem Nicht-Python-Programm. Dies führt wahrscheinlich zu Python-Tools / -Bibliotheken (wie dem Python-Interpreter selbst!), Auf die sich Benutzer auf Ihrem Computer möglicherweise verlassen. Dies ist kein Problem, solange sie die Abhängigkeiten verstehen und im Idealfall alternative Methoden kennen, um mit Hosts umzugehen, die diese Abhängigkeiten nicht bereitstellen.

Ein allgemeines und einfaches Beispiel für eine solche Abhängigkeit sind einige meiner persönlichen Skripte ~/.local/bin/, mit denen ich beginne #!/usr/bin/env python. Diese funktionieren unter RH / CentOS 7 und den meisten (aber nicht allen) Ubuntu-Installationen einwandfrei (sofern sie unter Python 2 ausgeführt werden). Sie werden nicht unter einer grundlegenden Debian-Installation oder unter Windows installiert. So sehr ich es nicht mag, dass mein persönliches Umfeld stark von Betriebssystempaketen abhängt (ich arbeite mit einer Reihe verschiedener Betriebssysteme), finde ich so etwas ziemlich akzeptabel. Mein Backup-Plan für die seltenen Hosts, die kein Python-System haben und keines bekommen können, besteht darin, mit einem Benutzersystem zu arbeiten, wie unten beschrieben.

Personen, die einen System-Python-Interpreter verwenden, sind normalerweise auch vom System abhängig pip3. Hier ziehe ich normalerweise die Grenze zu meinen Systemabhängigkeiten. alles von virtualenvvorn kümmere ich mich um mich. (Zum Beispiel ist mein Standard - activate Skript beruht auf , was auch immer pip3oder pipist auf dem Weg, sondern lädt seine eigene Kopie virtualenvder virtuellen Umgebung Bootstrap es zu schaffen.

Allerdings gibt es wahrscheinlich Umstände, unter denen es durchaus sinnvoll ist, eine Entwicklungsumgebung besser verfügbar zu machen. Möglicherweise verfügen Sie über Python-Schnittstellen in komplexen Paketen (z. B. einem DBMS), in denen Sie die Systemversion davon verwenden möchten, und Sie sind der Meinung, dass es am besten ist, wenn Sie das System den speziellen Python-Bibliothekscode auswählen lassen, mit dem Sie kommunizieren. Oder Sie stellen viele Hosts mit einer grundlegenden Entwicklungsumgebung für eine Python-Klasse bereit und finden es am einfachsten, sie mit Standardsystempaketen zu automatisieren.

Benutzer "Tages" -Programme und -Pakete

Benutzer verfügen möglicherweise über Python-Bibliotheken oder -Programme, die sich nicht gut in eine virtuelle Umgebung einfügen lassen, da sie beim Erstellen virtueller Umgebungen (z. B. virtualenvwrapper ) helfen sollen, oder sie sind Dinge, die Sie normalerweise auch während der Ausführung über die Befehlszeile verwenden Nicht-Python-Arbeit erledigen. Selbst wenn sie die Möglichkeit haben, Systemversionen davon zu installieren, fühlen sie sich möglicherweise wohler, wenn sie ihre eigenen installieren (z. B. weil sie die neueste Version des Tools und seine Abhängigkeiten verwenden möchten).

Im Allgemeinen pip --userwird dies verwendet, obwohl bestimmte Abhängigkeiten, wie der Python-Interpreter selbst, etwas mehr erfordern. pyenv und pythonz sind nützlich, um persönliche Interpreter ~/.local/binzu erstellen (unabhängig davon, ob sie als Standardinterpreter oder auf andere Weise installiert sind ), und natürlich kann man immer "von Hand" aus dem Quellcode erstellen, wenn die Entwicklerbibliotheken verfügbar sind.

Ich versuche, das Nötigste, was hier installiert ist, beizubehalten: virtualenvwrapper (weil ich es ständig benutze) und vielleicht die neueste Version von pip. Ich versuche, Abhängigkeiten außerhalb der Standardbibliothek oder von Python 3 zu vermeiden, damit persönliche Skripte, die ich schreibe, auf vielen Hosts verwendet werden können. (Allerdings werden wir sehen, wie lange ich das durchhalten kann, wenn ich mehr und mehr dieser persönlichen Skripte nach Python verschiebe.)

Separate Anwendungsentwicklungs- und Laufzeitumgebungen

Dies ist die übliche virtuelle Sache. Für die Entwicklung sollten Sie fast immer eine virtuelle Umgebung verwenden, um sicherzustellen, dass Sie keine Systemabhängigkeiten verwenden, oder häufig mehrere, um verschiedene Python-Versionen zu testen.

Diese virtuellen Umgebungen eignen sich auch für Anwendungen mit vielen Abhängigkeiten, bei denen Sie eine Verschmutzung Ihrer Benutzerumgebung vermeiden möchten. Zum Beispiel habe ich normalerweise ein virtuelles Env eingerichtet, um Jupyter- Notebooks und ähnliches zu betreiben .