pip Fehler externally managed environment lösen: So geht es sicher

Was bedeutet der pip Fehler externally managed environment, und was tun Sie sofort?

Der Fehler externally-managed-environment ist eine Schutzfunktion: pip verweigert die Installation in eine Python Umgebung, die Ihrem Betriebssystem oder einem anderen Paketmanager gehört. Der richtige erste Schritt ist einfach. Legen Sie im Projektordner eine virtuelle Umgebung (venv) an, aktivieren Sie sie und führen Sie pip install dort erneut aus.

In diesem Leitfaden erklären wir, Talha Aslan und Team, warum die Meldung erscheint, welche Lösung zu welcher Situation passt und wie Sie weiterarbeiten, ohne Ihr System zu beschädigen. Zum Beispiel sehen Sie die Meldung auf einem frischen Ubuntu Server, bei einer neuen Debian Installation oder mit Python aus Homebrew auf macOS. Die Befehle nennen wir kurz im Fließtext, damit Sie sie direkt übernehmen können.

Was genau sagt die Meldung externally managed environment?

Wenn Sie pip install mit dem System Python ausführen, zeigt das Terminal einen Block, der mit error: externally-managed-environment beginnt. Darunter steht ein Hinweis ähnlich wie "This environment is externally managed" sowie ein Text, den Ihre Distribution verfasst hat. Dieser Text unterscheidet sich je nach System, denn PEP 668 erlaubt jedem Anbieter eine eigene Erklärung.

Der Kern ist klar. Jemand anderes verwaltet diese Python Installation, also apt, dnf oder Homebrew. Deshalb könnte pip hier Dateien überschreiben, die dieses Werkzeug abgelegt hat. Die Meldung nennt meist drei Wege:

• Das fertige Paket über den Paketmanager des Systems installieren.
• Eine virtuelle Umgebung anlegen und das Paket dort installieren.
• Für Kommandozeilenprogramme pipx verwenden.

Kurz gesagt ist die Meldung kein Defekt. Sie wirkt wie ein Verkehrsschild. Mit pip ist alles in Ordnung; das Werkzeug hält Sie lediglich davon ab, am falschen Ort zu installieren.

Was ist PEP 668, und warum gibt es diesen Schutz?

PEP 668 ist der Python Standard für "extern verwaltete Umgebungen". Er beschreibt eine Markierungsdatei namens EXTERNALLY-MANAGED, die ein Anbieter in den Ordner der Standardbibliothek legt. Findet pip diese Datei, lehnt es die Installation ab und zeigt die Warnung externally-managed-environment.

Warum also diese Regel? Unter Linux nutzen viele Systemwerkzeuge Python. Der Paketmanager installiert die passenden Bibliotheken in getesteten Versionen. Legen Sie danach mit pip eine andere Version derselben Bibliothek in den Systemordner, kann etwa ein Update Werkzeug ausfallen. Zudem ändern dann zwei Verwalter dieselben Dateien, ohne voneinander zu wissen. Daraus entstehen Fehler, die schwer zu finden sind.

Den vollständigen Text lesen Sie auf der Seite zu PEP 668. Die aktuelle technische Spezifikation steht im Python Packaging User Guide. So prüfen Sie das Verhalten Ihrer Distribution an einer Primärquelle.

Auf welchen Systemen erscheint diese Warnung?

Am häufigsten begegnet Ihnen die Warnung externally managed environment auf aktuellen Debian und Ubuntu Versionen, weil diese Distributionen die Markierungsdatei mitliefern. Außerdem können Fedora, auf Arch basierende Systeme und Homebrew Python auf macOS ähnlich vorgehen. Welche Version die Datei eingeführt hat, ändert sich mit der Zeit; prüfen Sie den aktuellen Stand daher in der offiziellen Dokumentation Ihrer Distribution.

Andererseits sehen Sie den Fehler in diesen Fällen meist nicht:

• Innerhalb einer aktiven virtuellen Umgebung.
• Mit dem offiziellen Windows Installer von python.org.
• Mit einem Python, das Sie über ein Werkzeug wie pyenv im Benutzerordner gebaut haben.
• In den offiziellen Python Docker Images, denn dort liegt Python auf einem eigenen Pfad.

Melden Sie sich zum Beispiel auf einem neuen Ubuntu Server an und tippen als Erstes pip install requests, sehen Sie den Fehler wahrscheinlich nach einer Minute. Deshalb gehört der Schritt zur virtuellen Umgebung ganz nach oben in Ihre Notizen zur Servereinrichtung.

Wie beheben Sie den Fehler mit einer virtuellen Umgebung (venv)?

Eine virtuelle Umgebung ist ein Python Ordner, der nur Ihrem Projekt gehört. Das eingebaute Modul venv legt sie ohne Zusatzwerkzeuge an. Darin schreibt pip in diesen Ordner statt in den Systemordner. Somit greift der Schutz externally-managed-environment gar nicht erst.

1. Wechseln Sie in Ihren Projektordner.
2. Legen Sie die Umgebung mit python3 -m venv .venv an.
3. Aktivieren Sie sie unter Linux und macOS mit source .venv/bin/activate.
4. Unter Windows führen Sie stattdessen .venv\Scripts\activate aus.
5. Danach starten Sie pip install paketname; die Installation läuft nun durch.

Unter Debian und Ubuntu meldet der erste Schritt eventuell, dass ensurepip nicht verfügbar ist. In diesem Fall installieren Sie das Modul venv mit sudo apt install python3-venv nach. Der genaue Paketname kann je nach Python Version leicht abweichen. Alle Optionen finden Sie in der venv Dokumentation auf python.org.

Hinweis: Die Aktivierung gilt nur für die aktuelle Terminalsitzung. Öffnen Sie ein neues Terminal, aktivieren Sie die Umgebung also erneut.

Warum ist die virtuelle Umgebung die richtige Standardlösung?

Eine virtuelle Umgebung behebt die Ursache, statt das Symptom zu verstecken. Jedes Projekt erhält eigene Bibliotheksversionen, deshalb beeinflusst ein Paket in einem Projekt nie ein anderes. Außerdem bleibt Ihr System Python sauber. Updates des Betriebssystems kollidieren somit nicht mit Paketen, die Sie selbst ergänzt haben.

Aus unserer Praxis wissen wir: Am meisten Zeit kostet das klassische Problem "bei mir läuft es". Auch das reduziert eine venv. Sie speichern die Ausgabe von pip freeze in einer Datei requirements.txt und bauen dieselbe Umgebung auf einem anderen Rechner nach. Zudem löschen Sie bei einem Defekt einfach den Ordner .venv und erstellen ihn in wenigen Minuten neu. Das System selbst hat keinen solchen Neustartknopf.

Dieselbe Logik gilt bei fehlenden Modulen. Haben Sie ein Paket installiert und Python findet es trotzdem nicht, liegt das Paket vermutlich in einer Umgebung, während Ihr Code in einer anderen läuft. Diesen Fall behandeln wir in unserem Leitfaden zu ModuleNotFoundError: No module named, daher wiederholen wir ihn hier nicht.

Was ist pipx, und wann wählen Sie es statt venv?

pipx installiert in Python geschriebene Kommandozeilenprogramme und gibt jedem Programm eine eigene virtuelle Umgebung. Möchten Sie also ein Werkzeug wie black oder httpie überall verfügbar haben, ist pipx die richtige Wahl. Es isoliert jede Anwendung und trägt ihren Befehl in Ihren PATH ein.

Die Einrichtung ist kurz. Unter Debian und Ubuntu holen Sie das Werkzeug mit sudo apt install pipx, auf macOS mit brew install pipx. Danach sorgt pipx ensurepath dafür, dass Ihre Shell die installierten Programme findet. Schließlich führen Sie pipx install programmname aus.

Allerdings passt pipx nicht zu jeder Aufgabe. Bibliotheken, die Ihr Code importiert, etwa requests oder pandas, gehören in die virtuelle Umgebung des Projekts. Anders gesagt: pipx für ein Werkzeug, das Sie als Befehl starten, venv für eine Bibliothek, die Ihr Code nutzt. Die offizielle Empfehlung finden Sie im Python Packaging User Guide zu pipx.

Wann ist die Installation über den Paketmanager des Systems sinnvoll?

Manchmal hat Ihre Distribution die benötigte Bibliothek bereits paketiert. Unter Debian und Ubuntu tragen solche Pakete meist ein Präfix, etwa python3-requests für requests. Installieren Sie es mit sudo apt install, gelangt die Bibliothek auf dem offiziellen Weg ins System Python. Der Schutz externally-managed-environment spielt dabei keine Rolle.

Dieser Weg lohnt sich vor allem in folgenden Fällen:

• Ein kleines Verwaltungsskript soll ohne zusätzliche Umgebung auf dem System laufen.
• Die von der Distribution getestete Version reicht Ihnen aus.
• Sicherheitsupdates sollen zusammen mit den normalen Systemupdates kommen.

Allerdings hinken Distributionspakete oft der neuesten Version hinterher. Braucht Ihr Projekt eine bestimmte oder neue Version, bietet eine virtuelle Umgebung mehr Spielraum. Außerdem existiert nicht für jede Bibliothek ein Distributionspaket. Suchen Sie also zuerst mit apt search, bevor Sie davon ausgehen.

Wie schneiden die Lösungen für externally managed environment im Vergleich ab?

Die folgende Tabelle fasst Ihre Optionen beim Fehler externally managed environment nach Bedarf zusammen. Lesen Sie sie mit Blick auf Ihr eigenes Szenario. Es gibt keine einzige richtige Antwort, nur das passende Werkzeug.

Zusammengefasst ist venv für die meisten Leser die erste Wahl, pipx folgt an zweiter Stelle. Das Systempaket lohnt sich nur, wenn Ihre Distribution bereits eine passende Version anbietet.

Warum ist --break-system-packages eine riskante Abkürzung?

Die Fehlermeldung erwähnt zudem eine Option --break-system-packages, mit der Sie die Prüfung umgehen. Schon der Name ist eine Warnung. In der Praxis erlaubt diese Option, absichtlich in den Bereich des Paketmanagers zu schreiben. Wir empfehlen sie nicht als Lösung und erklären das Risiko nur auf der Ebene des Konzepts.

Das Risiko entsteht als Kette. Zunächst ersetzt pip eine Bibliothek, von der Systemwerkzeuge abhängen, durch eine neuere oder ältere Version. Dann weiß der Paketmanager nichts von dieser Änderung. Beim nächsten Systemupdate fällt entweder das Werkzeug aus, oder das Update überschreibt Ihre Datei. Folglich können sowohl das Systemwerkzeug als auch Ihr Projekt scheitern. Herauszufinden, wer welche Datei geändert hat, wird außerdem deutlich schwerer.

Ebenso riskant ist es, die Markierungsdatei zu löschen oder die Prüfung in den pip Einstellungen dauerhaft abzuschalten. Solche Schritte bringen die Meldung zum Schweigen, beseitigen aber nicht die Ursache. Deshalb meiden Sie diesen Weg außerhalb eines einmaligen Testcontainers, den Sie danach verwerfen. Selbst dort ist eine virtuelle Umgebung meist weniger Aufwand.

Warum macht sudo pip install alles schlimmer?

Viele ältere Anleitungen raten: "Bei einem Rechtefehler einfach sudo davor setzen." Bei der Warnung externally-managed-environment hilft das nicht, denn die Prüfung betrifft den Besitz der Umgebung und nicht die Rechte. Zudem bedeutet sudo mit pip, Pakete aus dem Internet mit Administratorrechten in Systemordner zu schreiben.

Daraus entstehen zwei Probleme. Erstens kann ein Paket während der Installation Code mit vollen Rechten ausführen; bei allem, dem Sie nicht voll vertrauen, ist das ein ernstes Sicherheitsrisiko. Zweitens entstehen Dateien, die dem Administrator gehören, an Orten, die Sie später als normaler Benutzer nutzen. Danach erwarten Sie bei jeder Installation verwirrende Rechtefehler. Somit hinterlässt sudo ein Durcheinander, das schwerer aufzuräumen ist.

Die richtige Gewohnheit ist einfach. Starten Sie pip fast immer in einer aktiven virtuellen Umgebung und als normaler Benutzer. Administratorrechte brauchen Sie nur für Systempakete wie das Modul venv oder pipx.

Was tun Sie auf Servern, in Docker und in der CI?

Für eine Webanwendung auf einem Server gilt dieselbe Regel. Legen Sie im Ordner der Anwendung eine virtuelle Umgebung an und tragen Sie in der Dienstdefinition deren Python Interpreter ein. Dadurch reagieren die Abhängigkeiten der Anwendung nicht auf Systemupdates. Laufen mehrere Projekte auf dem Server, arbeitet zudem jedes sauber in seiner eigenen Umgebung.

In Docker gibt es zwei typische Fälle. Mit dem offiziellen Python Image sehen Sie den Fehler selten, denn dort liegt Python auf einem eigenen Pfad. Installieren Sie Python dagegen mit apt in einem Debian oder Ubuntu Basisimage, gilt der Schutz externally-managed-environment auch im Image. Dann ist eine virtuelle Umgebung im Image eine saubere Lösung. Sind Container neu für Sie, hilft unser Leitfaden zu Docker und Containern.

In CI Pipelines, also Abläufen, die bei jeder Codeänderung automatisch Tests starten, setzen Sie die Einrichtung der virtuellen Umgebung an den Anfang. So folgen Sie lokal und in der CI demselben Weg. Das erspart viele Überraschungen nach dem Muster "nur in der CI kaputt".

Warum bleibt der Fehler in Jupyter, VS Code und anderen Editoren bestehen?

Manchmal legen Sie die Umgebung an und installieren das Paket, doch Ihr Editor nutzt weiterhin das System Python. Führen Sie dann im eingebauten Terminal pip install aus, erscheint die Warnung externally-managed-environment erneut. Das Problem liegt also nicht an der Umgebung. Es liegt am Interpreter, den Ihr Editor gewählt hat.

Zur Lösung öffnen Sie die Interpreterauswahl Ihres Editors und wählen das Python im Ordner .venv des Projekts. VS Code bietet das meist über einen Befehl in der Befehlspalette an. Menünamen ändern sich zwischen Versionen, suchen Sie daher den passenden Bereich in der Oberfläche. Nutzen Sie Jupyter, installieren Sie ipykernel in der Umgebung und melden Sie sie als eigenen Kernel an.

Für eine schnelle Prüfung tippen Sie which python ins Terminal, unter Windows where python. Zeigt die Ausgabe den Ordner .venv nicht, ist die Umgebung nicht aktiv. Außerdem verrät python -m pip --version genau, zu welchem Python Ihr pip gehört.

Warum lösen KI Assistenten und kopierte Skripte diesen Fehler so oft aus?

Viele Entwickler kopieren heute Befehle aus KI Assistenten oder aus Skripten im Netz direkt ins Terminal. Ein Teil davon stammt aus älteren Umgebungen ohne diesen Schutz. Ein Skript sagt zum Beispiel "pip install dieses Paket", Sie starten es mit dem System Python, und der Fehler externally-managed-environment erscheint.

Die schlechteste Reaktion ist, den zweiten Vorschlag des Assistenten, also --break-system-packages, ungeprüft zu übernehmen. Geben Sie dem Assistenten stattdessen die klare Anweisung, das Projekt in einer virtuellen Umgebung einzurichten. Wie terminalbasierte Assistenten arbeiten, erklären wir in unserem Beitrag zu Claude Code. Dort gilt dasselbe Prinzip.

Zudem lohnt es sich, einen Befehl vor dem Ausführen zu lesen. Sehen Sie sudo, --break-system-packages oder einen Schreibzugriff auf Systemordner, halten Sie an und probieren Sie den Weg über die virtuelle Umgebung. Mehr Hintergrund zu den Risiken schnellen, assistentengetriebenen Programmierens liefert unser Beitrag zu Vibe Coding.

Beispielszenario: ein Skript auf einem neuen Server starten

Stellen Sie sich als Beispielszenario einen Onlineshop vor, der jede Nacht seine Produktliste mit einem kleinen Python Skript exportieren möchte. Das Team zieht das Skript auf einen frischen Ubuntu Server um. Beim ersten Versuch scheitert pip install requests mit dem Fehler externally-managed-environment.

Der richtige Ablauf sieht so aus. Zunächst legen Sie im Skriptordner mit python3 -m venv .venv eine Umgebung an. Danach aktivieren Sie sie, installieren die Bibliotheken und speichern die Ausgabe von pip freeze in requirements.txt. Schließlich ruft der geplante Auftrag das Skript direkt über .venv/bin/python auf. Der Auftrag muss die Umgebung somit nicht einmal aktivieren.

Nutzt das Skript reguläre Ausdrücke, um Dateinamen oder Datumsmuster zu lesen, spart Ihnen unser Leitfaden zu Regex Zeit. Möchten Sie solche Automatisierungen sauber und wartbar für Ihr Unternehmen umsetzen lassen, sehen Sie sich unsere individuelle Softwareentwicklung an.

Welche Fehler passieren bei der Lösung am häufigsten?

Aus unserer Praxis kennen wir einige Fehler, die sich ständig wiederholen. Wenn Sie diese vorher kennen, verlieren Sie weniger Zeit mit der Warnung externally managed environment:

• Die Umgebung anlegen, die Aktivierung vergessen und erneut das System pip starten.
• Die Umgebung in einem beliebigen Ordner außerhalb des Projekts anlegen und sie danach nicht mehr finden.
• Den Ordner .venv ins Git Repository aufnehmen, statt ihn in .gitignore einzutragen.
• Für dieselbe Bibliothek ein Systempaket und ein pip Paket mischen.
• Die erste Abkürzung aus dem Netz anwenden, ohne die ganze Meldung zu lesen.

Vor allem ein eingecheckter Ordner .venv bläht Repositories mit nutzlosen Dateien auf. Außerdem enthält er Pfade, die auf anderen Betriebssystemen nicht funktionieren. Teilen Sie stattdessen eine Datei requirements.txt oder eine vergleichbare Liste. Für eine Auffrischung zu Git empfehlen wir unsere Anleitung zu den wichtigsten Git Befehlen.

Wie prüfen Sie nach dem Fehler, ob Ihr System intakt ist?

Da die Warnung die Installation vor dem Start stoppt, ist Ihr System in der Regel intakt. Haben Sie die Warnung allerdings früher mit einer Abkürzung umgangen, liegen möglicherweise noch pip Pakete in Systemordnern. Dann hilft eine kurze Prüfung.

Starten Sie zunächst python3 -m pip list mit dem System Python und vergleichen Sie die Liste mit dem, was Ihre Distribution installiert hat. Unter Debian und Ubuntu zeigt dpkg -l mit dem passenden Muster die Bibliotheken, die dem Paketmanager gehören. Pakete, die nur in der pip Liste auftauchen, haben Sie vermutlich selbst ergänzt.

Entfernen Sie diese nicht überstürzt. Notieren Sie zuerst, welches Skript oder welcher Dienst sie nutzt, und verlegen Sie diese Arbeit in eine virtuelle Umgebung. Erst danach entfernen Sie das Paket aus dem System. So fällt kein Dienst ohne Vorwarnung aus. Sind Sie unsicher, erstellen Sie vorher einen Snapshot des Servers als sicheren Rückweg.

Wie ziehen Sie ein bestehendes Projekt in eine virtuelle Umgebung um?

Läuft ein Projekt seit Jahren mit dem System Python, wirkt der Umzug vielleicht abschreckend. In der Praxis dauert er oft weniger als eine halbe Stunde. Folgen Sie dabei dieser Reihenfolge:

1. Listen Sie die Bibliotheken auf, die Ihr Code importiert.
2. Legen Sie im Projektordner eine neue virtuelle Umgebung an und aktivieren Sie sie.
3. Installieren Sie die Bibliotheken in dieser Umgebung.
4. Starten Sie das Projekt mit dem Python der Umgebung und beheben Sie jedes fehlende Modul.
5. Speichern Sie den funktionierenden Stand mit pip freeze in requirements.txt.
6. Stellen Sie geplante Aufträge und Dienste auf den Interpreter in .venv um.

Fehlende Module während des Umzugs sind normal. Sie beweisen, dass die Umgebung wirklich getrennt ist. Mit jedem ergänzten Paket wird Ihre Liste der Abhängigkeiten klarer. Folglich ist das Projekt zum ersten Mal dokumentiert und lässt sich auf einem anderen Rechner leicht nachbauen.

Wie legen Sie im Team einen Standard für Python Umgebungen fest?

Bei Einzelversuchen funktioniert fast jede Methode irgendwie. Sobald jedoch mehrere Entwickler an einem Projekt arbeiten, brauchen Sie einen gemeinsamen Standard. Sonst nutzt eine Person Systempakete und eine andere eine venv. Warnungen wie externally managed environment tauchen dann auf jedem Rechner anders auf.

Wir empfehlen einen einfachen Standard aus drei Punkten:

• Jedes Repository erwartet im Hauptordner einen Ordner .venv und trägt ihn in .gitignore ein.
• Die Abhängigkeiten stehen in einer Datei, die Sie bei jeder Änderung aktualisieren.
• Die README enthält die zwei oder drei Schritte zur Einrichtung der Umgebung.

Mit diesem Standard startet ein neuer Entwickler das Projekt am ersten Tag in wenigen Minuten. Außerdem folgen Server und CI denselben Schritten, deshalb werden Diskussionen nach dem Muster "bei mir geht es" kürzer. Kurz gesagt macht der Standard aus einem persönlichen Ärgernis einen Teamprozess.

Warum geht eine virtuelle Umgebung nach einem Python Upgrade kaputt?

Eine virtuelle Umgebung bleibt an den Interpreter gebunden, mit dem Sie sie erstellt haben. Ändert ein Upgrade der Distribution oder ein Homebrew Update die Hauptversion von Python, zeigen Verweise in der alten Umgebung eventuell auf einen Interpreter, den es nicht mehr gibt. Dann sehen Sie beim Aktivieren seltsame Fehler. Manchmal landen Sie sogar wieder beim System pip und treffen erneut auf die Warnung externally-managed-environment.

Die Lösung ist einfach und zeigt die eigentliche Stärke einer venv. Löschen Sie zunächst den alten Ordner .venv. Dann führen Sie python3 -m venv .venv mit dem neuen Python erneut aus. Schließlich stellen Sie die Abhängigkeiten mit pip install -r requirements.txt wieder her. Mit einer aktuellen Liste dauert das nur wenige Minuten.

Behandeln Sie die Umgebung daher nie wie einen wertvollen, von Hand gepflegten Ordner. Sie ist ein Wegwerfprodukt; wertvoll ist die Liste der Abhängigkeiten. Diese Sicht nimmt außerdem den Stress vor großen Systemupgrades, denn der Weg zum Neuaufbau jedes Projekts liegt bereits schriftlich vor.

Ist die Warnung ein Fehler oder eine Funktion, die Sie schützt?

Beim ersten Mal wirkt die Meldung externally managed environment lästig. Ein Befehl, der gestern lief, stoppt heute. Langfristig hält dieser Schutz das Python Ökosystem jedoch gesünder. Systemwerkzeuge finden die erwarteten Bibliotheken, und Sie verwalten jedes Projekt für sich.

Als Team sehen wir die Warnung als Anstoß zu einer besseren Gewohnheit. Sobald die virtuelle Umgebung fester Teil Ihres Arbeitsablaufs ist, verschwindet der Fehler von selbst. Zudem lässt sich ein Projekt dann problemlos an einen anderen Entwickler übergeben oder auf einen neuen Server umziehen.

Konzentrieren Sie sich also darauf, die Meldung zu verstehen, statt sie zum Schweigen zu bringen. Nutzen Sie pipx für Kommandozeilenprogramme, venv für Projektbibliotheken und den Paketmanager des Systems für Bibliotheken, die Ihre Distribution bereits liefert. Mit diesen drei Regeln entstehen die meisten pip Probleme gar nicht erst. Weitere praktische Helfer finden Sie auf unserer Seite mit kostenlosen Tools.

Was sollten Sie als Nächstes lernen?

Haben Sie den Fehler externally-managed-environment behoben, ist der nächste sinnvolle Schritt eine systematische Verwaltung der Abhängigkeiten. Halten Sie die Liste der Bibliotheken ordentlich, legen Sie Versionen fest und dokumentieren Sie die Umgebung. Das verhindert viele spätere Probleme. Wächst Ihr Projekt, rücken zudem containerbasierte Bereitstellung und automatische Testabläufe in den Blick.

Lernen Sie Python für KI Projekte, zeigt unsere Roadmap für KI mit Python, welches Werkzeug in welcher Phase sinnvoll ist. Bei der Auswahl von Bibliotheken hilft unser Überblick über beliebte Python Bibliotheken. Und soll Ihre Anwendung mit anderen Diensten sprechen, erklärt unser Beitrag zu APIs die Grundlagen in einfachen Worten.

Ein letzter Tipp: Sammeln Sie Ihre Notizen zur Einrichtung in einem gemeinsamen Dokument. Notieren Sie je Server eine kurze Zeile mit Betriebssystem, Python Version, Pfad der Umgebung und dem Befehl, der den Dienst startet. Kehren Sie dann nach Monaten zurück oder übergeben die Arbeit an eine Kollegin, muss niemand raten, welches pip in welchen Ordner schreibt.