Ein Python, viele Projekte

Jedes Programm, das du bisher geschrieben hast, bestand ausschließlich aus Dingen, die Python bereits mitbringt. Das ist eine echte Leistung und zugleich ungewöhnlich. Die meisten Python-Programme im praktischen Einsatz stützen sich auf Code, den jemand anderes geschrieben hat.

Code, den du nicht selbst geschrieben hast

Angenommen, dein Programm soll eine Seite aus dem Internet abrufen. Du könntest selbst herausfinden, wie das Protokoll funktioniert, was Wochen sorgfältiger Arbeit erfordert. Oder du nutzt den Code, den jemand genau dafür bereits geschrieben und getestet hat.

Diese zweite Möglichkeit ist ein Paket: ein wiederverwendbares Bündel Python-Code, das du einem Projekt bewusst hinzufügst. Viele Pakete stammen von anderen; ein Team kann aber auch seinen eigenen gemeinsam genutzten Code als Paket bereitstellen. Sobald ein Paket in einer Umgebung installiert ist, können Programme, die diese Umgebung nutzen, es importieren.

Fundamentals I hat Pakete ausdrücklich ausgeklammert. Während du die Sprache selbst gelernt hast, war das die richtige Entscheidung. In diesem Kapitel ändert sich das. Am Ende wirst du ein Paket installiert, den Bedarf deines Projekts festgehalten und die gesamte Einrichtung von Grund auf wiederhergestellt haben.

Es gibt einen Haken. Um ihn geht es im Rest dieser Lektion.

Zwei Projekte, ein Regal

Ein Paket wird nicht einmal geschrieben und ist dann fertig. Es wird korrigiert und erweitert, und jede Veröffentlichung bekommt eine Versionsnummer. Dein Programm braucht nicht einfach „dieses Paket“, sondern eine Version, deren Verhalten zu deinem Code passt.

Die Shell kann dein Programm jetzt ausführen. Programme, die diese Python-Umgebung verwenden, greifen aber weiterhin auf dieselbe Sammlung installierter Pakete zu. Stell dir das als ein gemeinsames Regal vor.

Stell dir ein Wetterprojekt vor, das für Version 2 eines Pakets geschrieben wurde. Einen Monat später beginnst du ein Reiseprojekt, das Version 3 braucht. Wenn du Version 3 ins gemeinsame Regal stellst, funktioniert das Wetterprojekt möglicherweise plötzlich nicht mehr, weil Version 2 einfach nicht mehr da ist. Keines der Programme ist falsch. Sie haben zu unterschiedlichen Zeiten unterschiedliche Voraussetzungen festgelegt, und ein Regal kann nicht beide erfüllen.

Die Grenze gehört zum Projekt

Eine nützliche Lösung ist eine kleine Python-Umgebung in jedem Projektverzeichnis. Das Wetterprojekt bekommt seine Paketversionen. Das Reiseprojekt bekommt eigene. Änderungen an der einen Umgebung räumen die andere nicht um.

Diese Abgrenzung heißt virtuelle Umgebung. Sie ist keine virtuelle Maschine und enthält kein weiteres Betriebssystem. Sie ist ein Verzeichnis, das einem Projekt einen eigenen Python-Befehl und einen eigenen Platz für installierte Pakete gibt.

Wir nennen das Verzeichnis .venv. Der Punkt am Anfang ist eine Konvention mit der Bedeutung: „Das unterstützt das Projekt; es gehört nicht zu dessen Quelldateien.“ Viele Editoren erkennen diesen Namen automatisch.

Austauschbar statt unersetzlich

Eine virtuelle Umgebung kann groß sein, enthält computerspezifische Pfade und wird von Werkzeugen erzeugt. Sie ist ein abgeleiteter Zustand, etwa wie eine angefertigte Kopie von etwas, dessen Bauanleitung du noch hast. Auf der Website von Python Land existiert sie nur in der Arbeitssitzung und wird ausgeschlossen, wenn der kleine Projektbaum gespeichert oder heruntergeladen wird.

Das ist beabsichtigt. Du solltest .venv löschen oder verlieren und anschließend eine gleichwertige Umgebung neu erstellen können. Der dauerhafte Teil ist eine kurze Textdatei, die angibt, was das Projekt braucht. Diese Datei erstellst du später im Kapitel.

Als Nächstes erstellst du diese Grenze und beobachtest, wie die Shell sie betritt.