alix apu auswahl bewegung buecher c cfengine checklisten computernetz debian dvcs ebtables email epub fairphone2 fedora firewall fossilscm grep hardware i2c iproute iptables ipv6 kalender kpartx latex laufen lighttpd linux lua lur monotone mount openvpn openwrt paketfilter perl postfix pxelinux python qubes-os rfc rpm rs232 schreiben script seriell shell software stehen sysadmin systemd troubleshoot ubuntu uci vcs virtualbox virtuell vpn wine xen

Eine virtuelle Umgebung für Python

Virtuelle Umgebungen haben etwas für sich. Ich kann sie einrichten wie ich will und muss keine Rücksicht auf den Rest des Systems nehmen.

Nicht allein kann ich meine Umgebung damit anders als die Systemumgebung einrichten, manchmal muss ich das. Meist wenn ich für ein Projekt eine Software brauche, die neuere oder ältere Bibliotheken benötigt, als im System vorhanden. Dann kann ich versuchen, durch die Abhängigkeitshölle zu gehen, und die Software mit der aktuellen Systemumgebung zum Laufen zu bringen. Oder ich setze eine virtuelle Umgebung auf, die alle Abhängigkeiten erfüllt.

Eine schöne Sache also. Außerdem gibt es die virtuellen Umgebungen in verschiedenen Spielarten. Es gibt

  • virtuelle Maschinen, die einen kompletten Rechner nebst Betriebssystem bereitstellen,
  • Container, die nur die nötigste Software in einer Prozessgruppe enthalten und
  • virtuelle Umgebungen, die nur die benötigten Bibliotheken für eine Programmiersprache bereitstellen.

Für Python ist virtualenv so eine Umgebung. Darin werden über Umgebungsvariablen die Pfade für die zu verwendenden Bibliotheken verstellt, so dass die virtuelle Umgebung unabhängig von den Pythonbibliotheken des Betriebssystems ist.

Natürlich benötigt das mehr Plattenplatz, da etliche Bibliotheken nun wieder mehrfach im vorhanden sind. Aber dieser Platz ist erheblich billiger als die Arbeitszeit, die draufgeht, um eine neue Software an das System oder - noch schlimmer - das System an eine neue Software anzupassen.

Installation

Damit genug der Vorrede, probieren wir die Sache aus.

Zunächst einmal brauche ich das Program virtualenv, mit dem ich mir die einzelnen Umgebungen einrichten kann.

Bei Fedora finde ich dieses im Paket python3-virtualenv, das ich mir mit dnf installiere:

sudo dnf install python3-virtualenv

Damit bin ich schon fertig mit der Installation. Das Software-Paket enthält das Program virtualenv (eventuell mit angefügter Versionsnummer), mit dem ich mir virtuelle Umgebungen für Python einrichten kann.

Verwendung

Jetzt habe ich die Software für die virtuellen Umgebungen, wie verwende ich diese nun?

Eine virtuelle Umgebung anlegen

Als erstes - und das muss ich pro Projekt nur einmal tun - lege ich eine virtuelle Umgebung an.

Ich bewege mich in das Projektverzeichnis und rufe virtuelenv mit dem Namen des Verzeichnisses auf, in dem die Bibliotheken der virtuellen Umgebung abgelegt werden sollen.

cd $project
virtualenv venv

Dieses Verzeichns nenne ich meist venv und zwar aus einem guten Grund, der beim Weiterlesen gleich klar wird.

Die virtuelle Umgebung aktivieren

Jedesmal, wenn ich in meinem Objekt mit der virtuellen Umgebung arbeiten will, muss ich diese aktivieren. Das allerdings nur einmal, bevor ich anfange zu arbeiten.

cd $project
source venv/bin/activate
...

Da ich nicht soviel tippen will, baue ich mir einen Alias für die Bash, meine bevorzugte Shell.

alias venv_activate='source venv/bin/activate'

Dieser Alias ist nicht soviel kürzer als der eigentliche Befehl. Weil es aber nur ein Wort ist, spare ich mit der Command Line Completion einiges gegenüber dem source Befehl mit dem Verzeichnispfad.

Und damit der Alias bei jedem Projekt mit einer virtuellen Umgebung funktioniert, nenne ich das zugehörige Verzeichnis eben venv.

Die virtuelle Umgebung deaktivieren

Wenn ich die virtuelle Umgebung nicht mehr benötige, kann ich sie mit folgendem Befehl deaktivieren.

deactivate

In den meisten Fällen ist es nicht schädlich, wenn ich in anderen Verzeichnissen mit dieser Python-Umgebung arbeite. Aber so setze ich formal einen Schlusspunkt unter meine Arbeit an diesem Projekt, und ausserdem komme ich nicht durcheinander, wenn ich anschließend in einem anderen Projekt mit eigener Python-Umgebung arbeite.

Software installieren

Habe ich die virtuelle Umgebung aktiviert, wie oben beschrieben, landen alle Python-Bibliotheken, die ich mit pip installiere, darin.

Um später die gleiche Umgebung auf einem anderen Rechner zur Verfügung zu haben, halte ich meinen aktuellen Stand in einer Textdatei fest:

pip freeze > python-requirements.txt

Die Datei python3-requirements.txt lege ich zusammen mit meinem Projekt im Repository ab und bin damit einen Schritt näher an reproducible Builds. Das Verzeichnis venv/ mit den Python-Modulen brauche ich nicht unbedingt beim Projekt ablegen.

Mit pip kann ich dann eine andere virtuelle Umgebung mit identischer Software einrichten, nachdem ich die Umgebung wie oben aufgesetzt habe:

pip install python-requirements.txt

Sphinx Dokumentationssystem

Am häufigsten verwende ich virtualenv, wenn ich Dokumentationen und Texte mit Sphinx schreibe.

Beim Einrichten lege ich nicht nur die virtuelle Umgebung an, sondern installiere Sphinx selbst in dieser Umgebung.

cd $project
source venv/bin/activate
pip install Sphinx

Nach der Installation halte ich den momentan Stand der Pakete fest und beginne das Projekt mit sphinx-quickstart:

pip freeze > python-requirements.txt
sphinx-quickstart

Alles weitere geht wie oben beschrieben.

Weiterführende Informationen

Detailliertere Informationen zu virtuelenv gibt es zum Beispiel beim Hitchhiker's Guide to Python.

Posted 2017-05-13 Tags:

Manuel
Posted 2017-04-27
Fairphone 2 Problem mit Slim Case
Posted 2017-04-02
Transparentes VPN-Gateway
Posted 2017-03-09
Eine Ubuntu 16.04 Xen DomU aufsetzen
Posted 2017-01-22
Wo platziere ich mein VPN Gateway?
Posted 2016-12-29
Kalender 2017
Posted 2016-11-21
Checklisten mit Handbuch
Posted 2016-08-17
Parsen von KDP Transaction Reports
Posted 2016-07-18
Skip the BOM
Posted 2016-04-03
Posted 2014-12-27