Schlank oder mit Extras, Terminal only oder IDE 6 Tools für virtuelle Python-Umgebungen

Das Python-Ökosystem neigt dazu, auszuufern – in jede Richtung. Die Verwaltung und der Einsatz von virtuellen Umgebungen bilden da keine Ausnahme. Über das native Tool „venv“ hinaus gibt es noch andere Werkzeuge, wir stellen einige davon vor.

Wie sich wechselhafte Abhängigkeiten virtueller Python-Umgebungen zähmen lassen, haben wir bereits erläutert. Was bleibt? Die Auswahl des passenden Tools.

Sicherlich könnte man einfach beim Standard bleiben, Python bringt schließlich nicht umsonst ein Modul namens venv mit. Aber vielleicht soll es doch ein wenig mehr sein? Verwaltung von Umgebungen etwa? Oder braucht es ein wenig Projektmanagement? Oder nur ein paar Komfortfunktionen als Ergänzung?

Übrigens: Auf welche Lösung auch immer die Wahl fällt, die Chancen stehen gut, dass es ein passendes VSC-Plug-in gibt. Alternativ ist es möglich, gleich den Python Environment Manager zu nutzen – eine Erweiterung, die mit vorhandenen Varianten zurechtkommt.

Der Standard: venv

Python selbst bringt schon die nötige Funktionalität mit: Mit dem Modul venv lassen sich ganz fix virtuelle Umgebungen bauen und anschließend mit Pip füllen – wie genau, zeigt die eingangs genannte Einführung.

Der Einsatz ist aber auch in der Kurzversion nachvollziehbar: Die virtuelle Umgebung wird mit „python -m venv .venv“ aufgebaut und liegt dann in Form des Ordners „.venv“ vor. Zum Benutzen muss sie aktiviert werden, unter Linux beispielsweise mittels „source .venv/bin/activate“. Der laufende Betrieb wird durch eine Erweiterung des Prompts durch „[.venv]“ angezeigt. Verlassen wird die Umgebung mit „deactivate“ und gelöscht mit „rm -r .venv“.

Für venv spricht, dass es der immer verfügbare Standard und sehr schlank ist. Das Modul bietet kaum eine Hand voll Optionen, die Ordnerstruktur ist nachvollziehbar, Hilfe und Dokumentation gibt es reichlich.

Standard Plus: virtualenv

Es liegt nahe, direkt folgend virtualenv zu platzieren – denn es ist die Basis des venv-Moduls, das lediglich einen Teil der Funktionalität implementiert und auch erst seit Python 3.3 mitgeliefert wird. Die grundsätzliche Handhabung entspricht der venv-Variante.

virtualenv bietet allerlei Vorteile, insbesondere Caching. Statt über pip lassen sich Programme über die Methode „app-data“ installieren, die schlicht auf bereits gebaute und im Nutzerverzeichnis abgelegte Images zurückgreift. Wird also beispielsweise eine Bibliothek in einer ersten virtuellen Umgebung über pip eingerichtet, kann sie in der nächsten Umgebung via app-data genutzt werden – was bei massivem Einsatz entsprechend Zeit spart.

Bei virtualenv gibt es überdies eine umfangreichere API, Erweiterungsmöglichkeiten und deutlich mehr Optionen auf der Kommandozeile. Der Preis dafür: Man muss sich etwas mehr mit dem Tool beschäftigen als mit dem No-Brainer venv – was schon mit der Installation von virtualvenv beginnt, für die es viele Wege gibt.

Auf einem hiesigen Windows-Testsystem ließ sich virtualenv zum Beispiel nur in einer venv-Umgebung einwandfrei installieren. Die dort erzeugte virtualenv-Umgebung lief dann wiederum abseits dieser venv-Umgebung. Die Nutzung in Kürze:

Standard Plus – plus Komfort: virtualnenvwrapper

Der Name deutet es schon an, virtualenvwrapper ist eine Erweiterung für virtualenv – und zwar eine, die sich definitiv lohnt! Der Wrapper vereinfacht den Umgang mit mehreren virtuellen Umgebungen enorm. Zum einen gibt es schlicht intuitivere Befehle. Beispielsweise erstellt „mkvirtualenv myenv1“ eine Umgebung und aktiviert sie auch direkt.

Zum anderen gibt es neue Funktionen, um etwa direkt von einer Umgebung in eine andere zu wechseln: „workon myenv2“ würde direkt die myenv2-Umgebung aufrufen, die wie andere mit dem Wrapper erzeugten Umgebungen (standardmäßig) unter „~/Envs“ zu finden ist. Auch hier die Nutzung in Kürze:

Ein Blick in die Befehlsreferenz von virtualenvwrapper lohnt durchaus. Hier gibt es zum Beispiel das Kommando „allvirtualenv“ zu entdecken, über das sich ein Befehl in allen verwalteten Umgebungen ausführen lässt – etwa zum Aktualisieren der jeweiligen pip-Versionen.

Alternative für Menschen: Pipenv

Der Schlachtruf von Pipenv ist unschlagbar: „Python-Entwickler-Workflow für Menschen.“ Pipenv automatisiert einige Aufgaben rund um pip und virtualenv. Statt also explizit eine Umgebung zu erstellen und anschließend zu aktivieren, genügt hier ein „pipenv shell“ im jeweiligen Projektordner, um beide Schritte durchzuführen. Und auch pip kann direkt verwendet werden: „pipenv install foobar“ installiert automatisch in der vorhandenen Umgebung des aktuellen Ordners und „pipenv run foobar“ würde entsprechend ausführen.

Ebenfalls praktisch: Statt einer manuellen Requirements-Datei nutzt das Helferlein eine eigene Datei „Pipfile.lock“, die die Paketinformationen um Hashes anreichert, was aus Security-Perspektive sehr erfreulich ist. Hinzu kommt die Datei „Pipfile“ mit einigen Projektspezifikationen, etwa den installierten Paketen (ohne Details). Auch der Blick in Abhängigkeiten und deren Abhängigkeiten über „pipenv graph“ dürfte in vielen Projekten von Vorteil sein.

Pipenv bietet ein paar Ansatzpunkte für die nähere Betrachtung, insbesondere die Lock-Dateien, ist aber insgesamt sehr übersichtlich und wird seinem Schlachtruf durchaus gerecht. Die Kombination von pip und virtualenv (und Python) unter einer Logik entspricht eher einer menschlichen Herangehensweise. Dabei bleibt pipenv transparent, pip und virtualenv sind klar zu erkennen. Die Nutzung:

Ein manuelles Verlassen/Deaktivieren der Umgebung ist hier nicht notwendig, eine mit „pipenv shell“ aufgerufene Umgebungs-Shell wird wie gewohnt mit „exit“ verlassen.

Alternative zur Alternative: Poetry

PoetryPoetry hätte auch gut vor pipenv stehen können, der Bekanntheitsgrad ist deutlich größer – allerdings auch der Funktionsumfang. Das Programm deckt noch mehr das Thema Projektmanagement ab und kann auch den Bau sowie die Veröffentlichung eines Projekts handhaben.

Im Mittelpunkt von Poetry steht eine Projektdatei im TOML-Format, nicht ganz unähnlich der Pipfile-Datei von pipenv. Darin finden sich Metadaten zum Projekt, Abhängigkeiten und Informationen zum Build-System, alles erfreulich gut auf der Peotry-Webseite dokumentiert. Und auch hier gibt es wieder eine Lock-Datei samt Hashes, um exakte Re-Installation zu ermöglichen.

Aber schon bei den ersten Schritten werden die Unterschiede deutlich. Den Anfang bei Poetry macht (oft) ein „poetry new“ – womit im aktuellen Ordner eine Datei- und Ordnerstruktur für ein neues Projekt gebaut wird, inklusive TOML- und zum Beispiel README-Datei. Über Einträge in der Projektdatei ließen sich nun Pakete installieren, nachdem die Lock-Datei aktualisiert wurde:

Freilich funktioniert dies auch direkt auf der Kommandozeile: „poetry add cowsay“ fügt das Paket „cowsay“ zur Projektdatei hinzu, aktualisiert die Lock-Datei und installiert es.

Auch das Betreten/Aktivieren einer Umgebung dürfte bekannt vorkommen: „poetry shell“ natürlich.

Auch wenn sich pipenv und Poetry sehr ähnlichsehen: Für viele Nutzer fühlt sich Poetry eher wie ein in sich geschlossenes System an, das die virtuellen Umgebungen im Hintergrund umsetzt. Während bei pipenv noch klar pip und virtualenv durchscheinen. Relevanter: In vielen Berichten aus größeren Projekten bescheinigen Nutzer Poetry besseren Umgang mit Abhängigkeiten! Zudem ist die Veröffentlichung auf PyPi einfacher. Andererseits: pipenv kann optionale Skripte ausführen. Eine glasklare Antwort auf die bessere Alternative gibt es wohl nicht.

Außenseiter: RCC

Bislang ging es nur um das pip-Universum – die Conda-Konkurrenz ist wieder ein ganz eigenes Biest. Dennoch sollt hier zum Abschluss kurz ein hoch interessanter Außenseiter genannt werden, RCC. RCC beschreiben wir zusammen mit dem venv-Modul ausführlich im ersten Artikel.

Das Besondere an RCC: Der gesamte Aufbau der virtuellen Umgebung wird deklarativ in einer YAML-Datei beschrieben, die zusammen mit der RCC-Binary ein komplett systemunabhängiges, portables Paket bildet. Soll also von Dritten getestet, benötigen diese nur den Befehl „rcc task shell“ – und schon wird die Umgebung aufgebaut und aktiviert. Und Post-Install-Skripte dürfen auch noch ausgeführt werden. Auf dem Zielrechner muss also auch kein Python vorhanden sein!

Und an all jene, die RCC noch nicht kennen: Das könnte daran liegen, dass es eigentlich für einen ganz konkreten Kontext entwickelt wurde, mit dem dieser Artikel gar nichts zu tun hat – unser Artikel zum Robot Framework allerdings schon.

(ID:50040692)