Pipenv: Eine Anleitung zum neuen Python Packaging Tool

Stellen Sie sich vor, Sie arbeiten an einem Python-Projekt, das ein Drittanbieterpaket wieflask verwendet. Sie müssen diese Anforderung angeben, damit andere Entwickler und automatisierte Systeme Ihre Anwendung ausführen können.

Sie beschließen also, die Abhängigkeit vonflaskin eine Datei vonrequirements.txtaufzunehmen:

Großartig, alles funktioniert lokal einwandfrei, und nachdem Sie Ihre App eine Weile gehackt haben, entscheiden Sie sich, sie in die Produktion zu verschieben. Hier wird es ein bisschen unheimlich ...

Die obigerequirements.txt-Datei gibt nicht an, welche Version vonflask verwendet werden soll. In diesem Fall installiertpip install -r requirements.txt standardmäßig die neueste Version. Dies ist in Ordnung, es sei denn, in der neuesten Version gibt es Änderungen an der Benutzeroberfläche oder am Verhalten, die unsere Anwendung beschädigen.

Nehmen wir für dieses Beispiel an, dass eine neue Version vonflask veröffentlicht wurde. Es ist jedoch nicht abwärtskompatibel mit der Version, die Sie während der Entwicklung verwendet haben.

Angenommen, Sie stellen Ihre Anwendung für die Produktion bereit und führen einpip install -r requirements.txtaus. Pip erhält die neueste, nicht abwärtskompatible Version vonflask, und einfach so bricht Ihre Anwendung… in der Produktion.

“But hey, it worked on my machine!” - Ich war selbst dort und es ist kein großartiges Gefühl.

Zu diesem Zeitpunkt wissen Sie, dass die Version vonflask, die Sie während der Entwicklung verwendet haben, einwandfrei funktioniert hat. Um Abhilfe zu schaffen, versuchen Sie, inrequirements.txtetwas spezifischer zu sein. Sie fügen der Abhängigkeit vonflaskversion specifier hinzu. Dies wird auch alspinning-Abhängigkeit bezeichnet:

Durch das Anheften der Abhängigkeit vonflaskan eine bestimmte Version wird sichergestellt, dasspip install -r requirements.txt die genaue Version vonflask festlegt, die Sie während der Entwicklung verwendet haben. Aber wirklich?

Beachten Sie, dassflask selbst ebenfalls Abhängigkeiten aufweist (diepip automatisch installiert). flaskelbst gibt jedoch keine genauen Versionen für seine Abhängigkeiten an. Zum Beispiel erlaubt es jede Version vonWerkzeug>=0.14.

Nehmen wir für dieses Beispiel erneut an, dass eine neue Version vonWerkzeug veröffentlicht wurde, die jedoch einen Show-Stopper-Fehler in Ihre Anwendung einführt.

Wenn Sie diesmalpip install -r requirements.txt in der Produktion ausführen, erhalten Sieflask==0.12.1, da Sie diese Anforderung festgelegt haben. Leider erhalten Sie die neueste fehlerhafte Version vonWerkzeug. Auch hier bricht das Produkt in der Produktion.

Das eigentliche Problem hierbei ist, dassthe build isn’t deterministic. Damit meine ich, dass pip bei gleicher Eingabe (derrequirements.txt-Datei) nicht immer dieselbe Umgebung erzeugt. Derzeit können Sie die genaue Umgebung, die Sie auf Ihrer Entwicklungsmaschine in der Produktion haben, nicht einfach replizieren.

Die typische Lösung für dieses Problem ist die Verwendung vonpip freeze. Mit diesem Befehl können Sie genaue Versionen für alle derzeit installierten Bibliotheken von Drittanbietern abrufen, einschließlich der automatisch installierten Unterabhängigkeiten pip. So können Sie alles in der Entwicklung einfrieren, um sicherzustellen, dass Sie dieselbe Produktionsumgebung haben.

Das Ausführen vonpip freeze führt zu fixierten Abhängigkeiten, die Sie zurequirements.txt hinzufügen können:

Mit diesen angehefteten Abhängigkeiten können Sie sicherstellen, dass die in Ihrer Produktionsumgebung installierten Pakete genau mit denen in Ihrer Entwicklungsumgebung übereinstimmen, damit Ihr Produkt nicht unerwartet kaputt geht. Diese „Lösung“ führt leider zu einer ganzen Reihe neuer Probleme.

Nachdem Sie die genauen Versionen aller Pakete von Drittanbietern angegeben haben, sind Sie dafür verantwortlich, diese Versionen auf dem neuesten Stand zu halten, auch wenn es sich um Unterabhängigkeiten vonflask handelt. Was ist, wenn inWerkzeug==0.14.1 eine Sicherheitslücke entdeckt wurde, die die Paketbetreuer sofort inWerkzeug==0.14.2 gepatcht haben? Sie müssen wirklich aufWerkzeug==0.14.2 aktualisieren, um Sicherheitsprobleme zu vermeiden, die sich aus der früheren, nicht gepatchten Version vonWerkzeug ergeben.

Zunächst müssen Sie sich darüber im Klaren sein, dass ein Problem mit Ihrer Version vorliegt. Dann müssen Sie die neue Version in Ihrer Produktionsumgebung herunterladen, bevor jemand die Sicherheitslücke ausnutzt. Sie müssen also Ihrerequirements.txt manuell ändern, um die neue VersionWerkzeug==0.14.2 anzugeben. Wie Sie in dieser Situation sehen können, liegt die Verantwortung, über die erforderlichen Aktualisierungen auf dem Laufenden zu bleiben, bei Ihnen.

Die Wahrheit ist, dass es Ihnen wirklich egal ist, welche Version vonWerkzeug installiert wird, solange Ihr Code nicht beschädigt wird. Wahrscheinlich möchten Sie mit der neuesten Version sicherstellen, dass Sie Fehlerbehebungen, Sicherheitspatches, neue Funktionen, mehr Optimierung usw. erhalten.

Die eigentliche Frage lautet:“How do you allow for deterministic builds for your Python project without gaining the responsibility of updating versions of sub-dependencies?”

Lassen Sie uns ein wenig die Gänge wechseln, um über ein weiteres häufiges Problem zu sprechen, das bei der Arbeit an mehreren Projekten auftritt. Stellen Sie sich vor, dassProjectAdjango==1.9 benötigt,ProjectB jedochdjango==1.10 benötigt.

Standardmäßig versucht Python, alle Pakete von Drittanbietern an einem systemweiten Speicherort zu speichern. Dies bedeutet, dass Sie jedes Mal, wenn Sie zwischenProjectA undProjectB wechseln möchten, sicherstellen müssen, dass die richtige Version vondjango installiert ist. Dies macht das Wechseln zwischen Projekten schmerzhaft, da Sie Pakete deinstallieren und neu installieren müssen, um die Anforderungen für jedes Projekt zu erfüllen.

Die Standardlösung besteht darin,virtual environment zu verwenden, das über eine eigene ausführbare Python-Datei und einen Paketspeicher von Drittanbietern verfügt. Auf diese Weise werdenProjectA undProjectB angemessen getrennt. Jetzt können Sie problemlos zwischen Projekten wechseln, da diese nicht denselben Speicherort für Pakete verwenden. PackageA kann jede Version vondjango haben, die es in seiner eigenen Umgebung benötigt, undPackageB kann das, was es braucht, völlig getrennt haben. Ein sehr verbreitetes Werkzeug hierfür istvirtualenv (odervenv in Python 3).

In Pipenv ist die Verwaltung virtueller Umgebungen integriert, sodass Sie ein einziges Tool für Ihre Paketverwaltung haben.

Was meine ich mit Abhängigkeitsauflösung? Angenommen, Sie haben einerequirements.txt-Datei, die ungefähr so ​​aussieht:

Angenommen,package_a hat eine Unterabhängigkeitpackage_c, undpackage_a erfordert eine bestimmte Version dieses Pakets:package_c>=1.0. package_b hat wiederum die gleiche Unterabhängigkeit, benötigt jedochpackage_c<=2.0.

Wenn Sie versuchen,package_a undpackage_b zu installieren, überprüft das Installationstool im Idealfall die Anforderungen fürpackage_c (>=1.0 und<=2.0) und wählt a aus Version, die diese Anforderungen erfüllt. Sie hoffen, dass das Tool die Abhängigkeiten auflöst, damit Ihr Programm am Ende funktioniert. Das meine ich mit "Abhängigkeitsauflösung".

Leider hat pip selbst im Moment keine echte Abhängigkeitsauflösung, aber es gibt einopen issue, um dies zu unterstützen.

Pip würde das obige Szenario wie folgt behandeln:

Hier beginnt das Problem (möglicherweise).

Wenn die von pip ausgewählte Version vonpackage_cnicht den zukünftigen Anforderungen entspricht (z. B.package_b, diepackage_c<=2.0benötigen), schlägt die Installation fehl.

Die „Lösung“ für dieses Problem besteht darin, den für die Unterabhängigkeit (package_c) erforderlichen Bereich in der Dateirequirements.txt anzugeben. Auf diese Weise kann pip diesen Konflikt lösen und ein Paket installieren, das diese Anforderungen erfüllt:

Wie zuvor beschäftigen Sie sich jetzt direkt mit Unterabhängigkeiten (package_c). Das Problem dabei ist, dass wennpackage_a ihre Anforderungen ohne Ihr Wissen ändert, die von Ihnen angegebenen Anforderungen (package_c>=1.0,<=2.0) möglicherweise nicht mehr akzeptabel sind und die Installation möglicherweise erneut fehlschlägt. Das eigentliche Problem besteht darin, dass Sie erneut dafür verantwortlich sind, über die Anforderungen von Unterabhängigkeiten auf dem Laufenden zu bleiben.

Im Idealfall ist Ihr Installationstool intelligent genug, um Pakete zu installieren, die alle Anforderungen erfüllen, ohne dass Sie explizit Unterabhängigkeitsversionen angeben.

Beginnen wir mit der Erstellung Ihrer fantastischen Python-Anwendung. Erstellen Sie zunächst eine Shell in einer virtuellen Umgebung, um die Entwicklung dieser App zu isolieren:

Dadurch wird eine virtuelle Umgebung erstellt, falls noch keine vorhanden ist. Pipenv erstellt alle Ihre virtuellen Umgebungen an einem Standardspeicherort. Wenn Sie das Standardverhalten von Pipenv ändern möchten, gibt es einigeenvironmental variables for configuration.

Sie können die Erstellung einer Python 2- oder 3-Umgebung mit den Argumenten--two und--three erzwingen. Andernfalls verwendet Pipenv alle Standardeinstellungen vonvirtualenv.

Jetzt können Sie das benötigte Drittanbieterpaketflask installieren. Oh, aber Sie wissen, dass Sie Version0.12.1 und nicht die neueste Version benötigen. Gehen Sie also vor und seien Sie genau:

In Ihrem Terminal sollte Folgendes angezeigt werden:

Sie werden feststellen, dass zwei Dateien erstellt werden,Pipfile undPipfile.lock. Wir werden uns diese in einer Sekunde genauer ansehen. Lassen Sie uns ein weiteres Paket eines Drittanbieters,numpy, installieren, um die Zahlen zu ermitteln. Sie benötigen keine bestimmte Version, geben Sie also keine an:

Wenn Sie etwas direkt von einem Versionskontrollsystem (VCS) installieren möchten, können Sie! Sie geben die Speicherorte ähnlich wie beipip an. Gehen Sie beispielsweise wie folgt vor, um dierequests-Bibliothek über die Versionskontrolle zu installieren:

Beachten Sie das obige Argument-e, um die Installation bearbeitbar zu machen. Derzeit istthis is requiredfür Pipenv erforderlich, um die Auflösung von Unterabhängigkeiten durchzuführen.

Nehmen wir an, Sie haben auch einige Komponententests für diese großartige Anwendung und möchtenpytest verwenden, um sie auszuführen. Sie benötigenpytest in der Produktion nicht, sodass Sie angeben können, dass diese Abhängigkeit nur für die Entwicklung mit dem Argument--devgilt:

Wenn Sie das Argument--devangeben, wird die Abhängigkeit an einer speziellen Stelle von[dev-packages]inPipfile abgelegt. Diese Entwicklungspakete werden nur installiert, wenn Sie das Argument--dev mitpipenv install angeben.

Die verschiedenen Abschnitte trennen Abhängigkeiten, die nur für die Entwicklung benötigt werden, von denen, die für die tatsächliche Funktionsweise des Basiscodes erforderlich sind. In der Regel wird dies mit zusätzlichen Anforderungsdateien wiedev-requirements.txt odertest-requirements.txt erreicht. Jetzt wird alles in einem einzigenPipfile unter verschiedenen Abschnitten konsolidiert.

Angenommen, Sie haben alles in Ihrer lokalen Entwicklungsumgebung zum Laufen gebracht und sind bereit, es in die Produktion zu bringen. Dazu müssen Sie Ihre Umgebung sperren, damit Sie sicherstellen können, dass Sie dieselbe in der Produktion haben:

Dadurch werden IhrePipfile.lockerstellt / aktualisiert, die Sie niemals manuell bearbeiten müssen (und sollen). Sie sollten immer die generierte Datei verwenden.

Sobald Sie Ihren Code undPipfile.lock in Ihrer Produktionsumgebung erhalten haben, sollten Sie die zuletzt aufgezeichnete erfolgreiche Umgebung installieren:

Dies weist Pipenv an, diePipfile für die Installation zu ignorieren und diePipfile.lock zu verwenden. Angesichts dieserPipfile.lock erstellt Pipenv genau dieselbe Umgebung, in der Siepipenv lock, Unterabhängigkeiten und alle ausgeführt haben.

Die Sperrdatei ermöglicht deterministische Builds, indem ein Snapshot aller Versionen von Paketen in einer Umgebung erstellt wird (ähnlich dem Ergebnis vonpip freeze).

Angenommen, ein anderer Entwickler möchte Ihren Code ergänzen. In dieser Situation würden sie den Code einschließlich derPipfile abrufen und diesen Befehl verwenden:

Dadurch werden alle für die Entwicklung erforderlichen Abhängigkeiten installiert, einschließlich der regulären Abhängigkeiten und derjenigen, die Sie mit dem Argument--dev währendinstall angegeben haben.

Dies ist ein wichtiger Hinweis, da er einige der zuvor diskutierten Probleme löst. Nehmen wir zur Demonstration an, dass eine neue Version einer Ihrer Abhängigkeiten verfügbar ist. Da Sie keine bestimmte Version dieser Abhängigkeit benötigen, geben Sie inPipfilekeine genaue Version an. Wenn Siepipenv install verwenden, wird die neue Version der Abhängigkeit in Ihrer Entwicklungsumgebung installiert.

Jetzt nehmen Sie Ihre Änderungen am Code vor und führen einige Tests durch, um sicherzustellen, dass alles noch wie erwartet funktioniert. (Sie haben Unit-Tests, richtig?) Jetzt sperren Sie wie zuvor Ihre Umgebung mitpipenv lock, und mit der neuen Version der Abhängigkeit wird ein aktualisiertesPipfile.lock generiert. Nach wie vor können Sie diese neue Umgebung in der Produktion mit der Sperrdatei replizieren.

Wie Sie in diesem Szenario sehen können, müssen Sie keine genauen Versionen mehr erzwingen, die Sie nicht wirklich benötigen, um sicherzustellen, dass Ihre Entwicklungs- und Produktionsumgebungen identisch sind. Sie müssen sich auch nicht über die Aktualisierung von Unterabhängigkeiten auf dem Laufenden halten, die Ihnen "egal" sind. Dieser Workflow mit Pipenv in Kombination mit Ihren hervorragenden Tests behebt die Probleme bei der manuellen Durchführung des gesamten Abhängigkeitsmanagements.

Pipenv wird versuchen, Unterabhängigkeiten zu installieren, die alle Anforderungen Ihrer Kernabhängigkeiten erfüllen. Wenn jedoch widersprüchliche Abhängigkeiten bestehen (package_abenötigtpackage_c>=1.0,package_bbenötigtpackage_c<1.0), kann Pipenv keine Sperrdatei erstellen und gibt einen Fehler wie aus folgende:

Wie in der Warnung angegeben, können Sie auch ein Abhängigkeitsdiagramm anzeigen, um Ihre Abhängigkeiten der obersten Ebene und ihre Unterabhängigkeiten zu verstehen:

Dieser Befehl druckt eine baumartige Struktur aus, in der Ihre Abhängigkeiten angezeigt werden. Hier ist ein Beispiel:

Aus der Ausgabe vonpipenv graph können Sie die zuvor installierten Abhängigkeiten der obersten Ebene (Flask,numpy,pytest undrequests) und darunter erkennen Sie können die Pakete sehen, von denen sie abhängen.

Darüber hinaus können Sie den Baum umkehren, um die Unterabhängigkeiten mit dem übergeordneten Element anzuzeigen, für das dies erforderlich ist:

Dieser umgekehrte Baum kann nützlicher sein, wenn Sie versuchen, widersprüchliche Unterabhängigkeiten herauszufinden.

Pipfile beabsichtigt,requirements.txt zu ersetzen. Pipenv ist derzeit die Referenzimplementierung für die Verwendung vonPipfile. Es scheint sehr wahrscheinlich, dasspip itself will be able to handle these files. Es ist auch erwähnenswert, dassPipenv is even the official package management tool recommended by Python itself.

Die Syntax fürPipfile lautetTOML, und die Datei ist in Abschnitte unterteilt. [dev-packages] für Nur-Entwicklungs-Pakete,[packages] für minimal erforderliche Pakete und[requires] für andere Anforderungen wie eine bestimmte Version von Python. Siehe eine Beispieldatei unten:

Idealerweise sollten Sie in IhrenPipfilekeine Unterabhängigkeiten haben. Damit meine ich, dass Sie nur die Pakete einschließen sollten, die Sie tatsächlich importieren und verwenden. Sie müssenchardet nicht inPipfile behalten, nur weil es sich um eine Unterabhängigkeit vonrequests handelt. (Pipenv installiert es automatisch.) DiePipfile sollten die Abhängigkeiten der obersten Ebene enthalten, die Ihr Paket benötigt.

Diese Datei ermöglicht deterministische Builds, indem die genauen Anforderungen für die Reproduktion einer Umgebung angegeben werden. Es enthält genaue Versionen für Pakete und Hashes, um eine sicherere Überprüfung zu unterstützen, auchpip itself now supports. Eine Beispieldatei könnte wie folgt aussehen. Beachten Sie, dass die Syntax für diese Datei JSON lautet und dass ich Teile der Datei mit... ausgeschlossen habe:

Notieren Sie die genaue Version, die für jede Abhängigkeit angegeben wurde. Sogar die Unterabhängigkeiten wiewerkzeug, die nicht in unserenPipfile enthalten sind, erscheinen in diesenPipfile.lock. Die Hashes werden verwendet, um sicherzustellen, dass Sie dasselbe Paket abrufen wie in der Entwicklung.

Es ist noch einmal erwähnenswert, dass Sie diese Datei niemals von Hand ändern sollten. Es soll mitpipenv lock erzeugt werden.

Öffnen Sie ein Paket eines Drittanbieters in Ihrem Standardeditor mit dem folgenden Befehl:

Dadurch wird das Paketflaskim Standardeditor geöffnet, oder Sie können ein Programm mit der UmgebungsvariablenEDITORangeben. Zum Beispiel verwende ichSublime Text, also setze ich nurEDITOR=subl. Auf diese Weise können Sie ganz einfach in die Interna eines von Ihnen verwendeten Pakets eintauchen.

Sie können einen Befehl in der virtuellen Umgebung ausführen, ohne eine Shell zu starten:

Überprüfen Sie Ihre Umgebung auf Sicherheitslücken (und die Anforderungen vonPEP 508):

Angenommen, Sie benötigen kein Paket mehr. Sie können es deinstallieren:

Angenommen, Sie möchten alle installierten Pakete vollständig aus Ihrer virtuellen Umgebung löschen:

Sie können--all durch--all-dev ersetzen, um nur Entwicklungspakete zu entfernen.

Pipenv unterstützt das automatische Laden von Umgebungsvariablen, wenn eine.env-Datei im Verzeichnis der obersten Ebene vorhanden ist. Auf diese Weise werden beim Öffnen der virtuellen Umgebungpipenv shell Ihre Umgebungsvariablen aus der Datei geladen. Die.env-Datei enthält nur Schlüssel-Wert-Paare:

Zum Schluss hier ein paar schnelle Befehle, um herauszufinden, wo sich etwas befindet. So finden Sie heraus, wo sich Ihre virtuelle Umgebung befindet:

So finden Sie heraus, wo sich Ihr Projekt befindet:

Wie funktioniert Pipenv mitsetup.py Dateien?

Diese Frage hat viele Nuancen. Erstens ist einesetup.py-Datei erforderlich, wenn Siesetuptools als Build- / Verteilungssystem verwenden. Dies ist seit einiger Zeit der De-facto-Standard, aberrecent changes haben die Verwendung vonsetuptools optional gemacht.

Dies bedeutet, dass Projekte wieflit die neuenpyproject.toml verwenden können, um ein anderes Build-System anzugeben, für das keinesetup.py erforderlich sind.

Alles, was gesagt wird, wird für die nahe Zukunftsetuptools und ein begleitendessetup.py für viele Menschen immer noch die Standardauswahl sein.

Hier ist ein empfohlener Workflow für den Fall, dass Siesetup.py verwenden, um Ihr Paket zu verteilen:

Geben Sie zur Verdeutlichung Ihre Mindestanforderungen insetup.py anstatt direkt inpipenv install ein. Verwenden Sie dann den Befehlpipenv install '-e .', um Ihr Paket als bearbeitbar zu installieren. Dadurch werden alle Anforderungen vonsetup.py in Ihre Umgebung übertragen. Dann können Siepipenv lock verwenden, um eine reproduzierbare Umgebung zu erhalten.

Toll! Wenn Sie eine Anwendung entwickeln, die nicht verteilt oder installiert werden soll (eine persönliche Website, eine Desktop-Anwendung, ein Spiel oder ähnliches), benötigen Sie keinesetup.py.

In dieser Situation können Sie die KombinationPipfile /Pipfile.lock verwenden, um Ihre Abhängigkeiten mit dem zuvor beschriebenen Ablauf zu verwalten und eine reproduzierbare Umgebung in der Produktion bereitzustellen.