ModuleNotFoundError: No module named in Python lösen

Was ist ModuleNotFoundError und was tun Sie zuerst?

ModuleNotFoundError ist die Fehlermeldung, die Python auslöst, wenn eine Import Zeile ein Modul nennt, das in keinem durchsuchten Ordner liegt. Meist fehlt das Paket, oder die Python Installation, die Ihren Code ausführt, ist nicht die, in die Sie es installiert haben. Bei jedem ModuleNotFoundError prüfen Sie zuerst, welcher Interpreter läuft und ob das Paket dort liegt.

Dieser Beitrag behandelt nur ein Problem: die Meldung No module named und den Einstieg in die Fehlersuche. Wir zeigen die Reihenfolge, die wir in der Praxis nutzen, von der häufigsten bis zur seltensten Ursache. Zunächst lohnt der Blick auf den Interpreter, denn in den meisten Fällen ist das Paket in Ordnung und der Interpreter falsch.

Außerdem hilft es, die Art des Fehlers zu kennen. ModuleNotFoundError ist eine Unterklasse von ImportError. Das heißt, Python sagt Ihnen gezielt, dass das Modul überhaupt nicht gefunden wurde. Die offiziellen Details finden Sie in der Referenz zum Import System von Python.

Wie lösen Sie ModuleNotFoundError in den ersten fünf Minuten?

Die folgenden Schritte gehen von der wahrscheinlichsten zur unwahrscheinlichsten Ursache. Starten Sie den Code nach jedem Schritt neu und beobachten Sie, ob sich die Meldung ändert.

1. Notieren Sie den Modulnamen aus der Meldung und prüfen Sie die Schreibweise.
2. Führen Sie python -m pip --version aus und prüfen Sie, ob der Pfad zur erwarteten Python Installation gehört.
3. Installieren Sie das Paket mit python -m pip install paketname, und zwar mit dem Python, das Ihren Code ausführt.
4. Nutzen Sie eine virtuelle Umgebung, aktivieren Sie diese zuerst und versuchen Sie es erneut.
5. Arbeiten Sie mit Editor oder Jupyter, prüfen Sie den gewählten Interpreter und den Kernel.
6. Stellen Sie sicher, dass keine eigene Datei denselben Namen wie das Modul trägt.
7. Bei eigenen Projektmodulen starten Sie die Datei aus dem Projektstamm, und zwar als Modul.

Schritt drei löst in der Praxis die meisten Fälle. Falls nicht, gehen die folgenden Abschnitte deshalb jede Ursache einzeln durch. Die Reihenfolge ist Absicht, denn wer ModuleNotFoundError sieht, installiert meist zuerst neu und prüft nie, welches Python das Paket bekommen hat.

Wie lesen Sie die Fehlermeldung richtig?

Die Meldung besteht also aus zwei Teilen: dem Modulnamen und manchmal einem Zusatzhinweis. Am häufigsten sehen Sie die Zeile No module named mit dem Namen in Anführungszeichen. Dieser Name ist genau das, was Python gesucht hat, denn er steht wörtlich in der Meldung. Lesen Sie ihn deshalb genau, bevor Sie etwas ändern.

Achten Sie zunächst auf Namen mit Punkten. Zum Beispiel kann eine Meldung zu einem Untermodul bedeuten, dass das übergeordnete Paket existiert, das Untermodul aber nicht. Manchmal endet die Meldung mit dem Hinweis, dass der übergeordnete Name kein Paket ist. Dann überdeckt meist eine Datei mit gleichem Namen das echte Paket.

Lesen Sie außerdem die Zeilen oberhalb der letzten Zeile im Traceback. Dort sehen Sie nämlich, welche Datei und welche Zeile den Import ausgelöst hat. Damit erkennen Sie also, ob das Problem in Ihrem Code oder in einer installierten Bibliothek liegt. Einen allgemeinen Ansatz finden Sie in unserem Leitfaden zu Debugging Techniken für Entwickler.

Hinweis: Bleiben Sie beim Lesen geduldig. Wer hastig Befehle ausprobiert, macht die Umgebung daher oft noch unübersichtlicher. Ändern Sie daher pro Schritt nur eine Sache und beobachten Sie das Ergebnis. So wissen Sie genau, was geholfen hat.

Ist das Paket wirklich installiert, und in welchem Python?

Das ist die Ursache, die wir in der Praxis am häufigsten sehen. Ein Rechner kann mehrere Python Installationen enthalten: die des Systems, eine aus einem Paketmanager, eine separate Installation und je Projekt eine virtuelle Umgebung. Der Befehl pip install richtet sich allerdings nur an eine davon, Ihr Code läuft aber vielleicht in einer anderen.

Die Lösung für diesen ModuleNotFoundError ist einfach, denn sie braucht nur einen Befehl. Rufen Sie pip über den Interpreter auf, der Ihren Code ausführt, statt pip direkt zu starten. Dann nutzen Installation und Ausführung immer dasselbe Python. Diese drei Zeilen machen die Lage klar.

python -c "import sys; print(sys.executable)"
python -m pip --version
python -m pip show paketname

Der erste Befehl gibt den Pfad des laufenden Python aus. Danach zeigt der zweite, zu welchem Python pip gehört. Schließlich verrät der dritte, ob das Paket installiert ist und wo. Weichen die beiden Pfade voneinander ab, haben Sie das Problem gefunden.

Auf manchen Systemen heißt der Befehl dagegen python3. Schreiben Sie dann oben python3 statt python. Installieren Sie außerdem keine Pakete per pip in das Python, das Ihr Betriebssystem verwaltet, denn manche Systeme blockieren das absichtlich. Legen Sie stattdessen für jedes Projekt eine eigene Umgebung an. Die Installationswege erklärt die Benutzeranleitung von pip.

Was passiert, wenn Ihre virtuelle Umgebung nicht aktiv ist?

Eine virtuelle Umgebung ist ein Ordner, der die Pakete eines Projekts vom System trennt. Starten Sie Code, ohne sie zu aktivieren, nutzt das Terminal das System Python. Die Pakete liegen aber in der Umgebung, weil Sie sie dort installiert haben. Folglich kann Ihr Code sie nicht sehen.

Am einfachsten erkennen Sie also die aktive Umgebung am Namen am Anfang der Eingabezeile. Um sicherzugehen, führen Sie den oben genannten Befehl mit sys.executable aus. Zeigt der Pfad in die Umgebung Ihres Projekts, ist die Aktivierung also gelungen.

Diese Schritte legen eine neue Umgebung an und nutzen sie:

python -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt

Unter Windows liegt das Aktivierungsskript in einem anderen Ordner. Die Einzelheiten stehen in der Dokumentation zu venv. Verschieben Sie einen Umgebungsordner an einen anderen Ort, zeigen seine Skripte außerdem womöglich weiter auf alte Pfade. Dann legen Sie die Umgebung neu an, statt sie zu verschieben. Die sicherste Gewohnheit lautet, immer python -m pip zu schreiben.

Kann Ihr Editor den falschen Interpreter nutzen?

Ja, und das ist sehr häufig, denn jedes Werkzeug merkt sich seine eigene Wahl. Editoren und IDEs verwenden beim Klick auf Ausführen ihren eigenen gewählten Interpreter. Zum Beispiel installieren Sie das Paket im Terminal, doch der Editor startet ein anderes Python. Der Fehler erscheint dann nur im Editor, während der Code im Terminal einwandfrei läuft.

So trennen Sie die Fälle: Starten Sie dieselbe Datei im Terminal mit der aktiven Umgebung. Läuft sie dort, liegt Ihr ModuleNotFoundError folglich an der Editor Einstellung. Öffnen Sie dann die Interpreter Auswahl Ihres Editors und wählen Sie die Umgebung Ihres Projekts. Menünamen ändern sich je nach Werkzeug, daher nennen wir keinen genauen Schaltflächentext. Suchen Sie den Abschnitt zum Interpreter in der Dokumentation Ihres Werkzeugs.

Trennen Sie außerdem den Linter von der echten Ausführung. Unterstreicht der Editor einen Import rot, das Programm läuft aber, schaut die Analyse vermutlich in die falsche Umgebung. In diesem Fall betrifft das Problem somit nur die Anzeige.

Warum nutzt ein Jupyter Notebook ein anderes Python?

Notebooks laufen auf einem Kernel, denn jeder Kernel hängt an genau einer Python Installation. Wenn Sie im Terminal eine Umgebung aktivieren und ein Paket installieren, ändert das den Kernel nicht. Deshalb kann ein Import im Terminal klappen und im Notebook scheitern.

Führen Sie zunächst diese Zeilen in einer Zelle aus und lesen Sie den Pfad:

import sys
print(sys.executable)

Zeigt der Pfad nicht auf die erwartete Umgebung, wechseln Sie den Kernel oder registrieren Sie einen neuen Kernel für diese Umgebung. Bei aktiver Umgebung gelingt das mit python -m ipykernel install --user --name projekt-umgebung. Zum Installieren im Notebook beginnen Sie eine Zeile mit dem Prozentzeichen und schreiben %pip install paketname. Dieser Befehl installiert somit in das Python des Kernels.

Nach der Installation müssen Sie den Kernel daher eventuell neu starten. Sonst bleibt der alte Zustand im Speicher und der Fehler besteht weiter. Wer mit KI in Python erst beginnt, findet in unserer Roadmap für KI mit Python ebenfalls Hinweise zur Einrichtung.

Warum kann der Paketname vom Importnamen abweichen?

Installationsname und Importname sind allerdings nicht immer gleich. Der Name, den Sie pip geben, ist der Name der Distribution. Der Name in Ihrem Code ist dagegen der Modulname. Ein Unterschied zwischen beiden ist erlaubt und ziemlich verbreitet.

Diese Liste ist nur ein Beispiel und keine Werkzeugempfehlung. Den richtigen Importnamen Ihres Pakets finden Sie deshalb in dessen offizieller Dokumentation. Installieren Sie unter einem falschen Namen, erhalten Sie entweder einen Fehler oder ein anderes Paket mit ähnlichem Namen. Kopieren Sie den Installationsbefehl daher von der Seite des Pakets selbst.

Möchten Sie die gängigen Bibliotheken besser kennenlernen, lesen Sie unseren Beitrag zu den beliebtesten Python Bibliotheken.

Was tun, wenn Ihre eigene Datei wie das Modul heißt?

Das nennt man Überdeckung, also Shadowing. Beim Import schaut Python nämlich zuerst in den Ordner des gestarteten Skripts. Liegt dort eine Datei namens random.py oder requests.py, lädt Python Ihre Datei statt des echten Moduls. Folglich fehlt ein Attribut, oder es erscheint ein merkwürdiger ModuleNotFoundError.

Das Symptom: Das Paket scheint installiert, pip show stimmt, und der Import scheitert trotzdem. Zum Beispiel legt jemand versehentlich requests.py an, sieht einen ModuleNotFoundError oder AttributeError und findet die Ursache nicht. Wirkt ein Fehler seltsam, listen Sie daher zuerst Ihren Ordner auf. Zur Diagnose geben Sie aus, aus welcher Datei ein Modul geladen wurde:

python -c "import json; print(json.__file__)"

Zeigt der Pfad in Ihren Projektordner statt in die Standardbibliothek oder den Ordner für installierte Pakete, ist Überdeckung die Ursache. Zunächst benennen Sie Ihre Datei um, danach löschen Sie alte Cache Ordner. Vermeiden Sie das Problem künftig, indem Sie Dateien nie nach Standardmodulen oder bekannten Paketen benennen. Selbst in schnellen Prototypen sind daher Namen wie test.py oder email.py tabu.

Warum scheitern Projektstruktur und relative Importe?

Bei eigenen Modulen liegt das Problem dagegen meist in der Art des Starts. Python baut den Importpfad aus dem Ort, an dem Sie das Skript starten. Starten Sie eine Datei direkt aus einem Unterordner, gelangt der Projektstamm nicht in den Pfad. Ein Modul im Nachbarordner wird dann nicht gefunden.

Beispielszenario: Im Projektstamm liegt ein Paket namens app mit der Datei service.py. Dann starten Sie diese Datei aus dem Unterordner, und ein anderes Modul fehlt. Starten Sie dieselbe Datei aus dem Projektstamm als Modul, verschwindet das Problem.

python -m app.service

Das Flag -m weist Python an, die Datei als Modul statt als Pfad auszuführen. Das Flag erklärt die Dokumentation zur Kommandozeile.

Historisch kennzeichnet eine Datei __init__.py einen Ordner als Paket. Modernes Python behandelt Ordner ohne diese Datei zudem als Namensraum Pakete. Eine leere __init__.py bleibt dennoch eine sichere und klare Wahl, wenn Sie ein ausdrückliches Paket wollen.

Worin unterscheiden sich relative und absolute Importe?

Ein absoluter Import schreibt den vollständigen Pfad des Pakets. Ein relativer Import gibt dagegen mit Punkten einen Pfad ab dem aktuellen Paket an. Relative Importe funktionieren nur innerhalb eines Pakets, in Dateien, die als Modul laufen. Starten Sie die Datei direkt als Skript, scheitert der relative Import.

Deshalb sind absolute Importe in der Startdatei Ihrer Anwendung sicherer. Machen Sie Ihr Projekt außerdem zu einem installierbaren Paket, bleibt der Importpfad in jeder Umgebung gleich. Das Projekt während der Entwicklung im bearbeitbaren Modus zu installieren, ist der praktische Weg dafür. Die Schritte finden Sie im Python Packaging User Guide.

Kurz gesagt gilt diese Regel: Starten Sie den Einstiegspunkt aus dem Projektstamm mit -m und bevorzugen Sie im Paket absolute Importe.

Was ist PYTHONPATH und wann brauchen Sie es?

PYTHONPATH ist eine Umgebungsvariable, die zusätzliche Ordner für die Modulsuche auflistet. Python schaut zuerst in den Ordner des laufenden Skripts, dann in die Ordner dieser Variable und zuletzt in die Standardbibliothek und die installierten Pakete. Ein Ordner, den Sie dort eintragen, gehört dann zum Importpfad.

Trotzdem empfehlen wir PYTHONPATH nicht als erste Lösung. Die Einstellung hängt am Rechner und fehlt daher auf einem anderen Computer oder in der CI. Dann läuft der Code bei Ihnen und scheitert bei Ihrer Kollegin. Korrigieren Sie zuerst die Paketstruktur und machen Sie das Projekt danach installierbar.

Für einen schnellen Test können Sie die Variable nur für einen einzelnen Befehl setzen. Das ist weniger riskant, denn es wird keine dauerhafte Einstellung. Ob der Pfad wirklich ankam, sehen Sie mit python -c "import sys; print(sys.path)", indem Sie die Liste lesen.

Behandeln Sie PYTHONPATH also wie ein Pflaster. Die echte Lösung ist eine saubere Projektstruktur, die ModuleNotFoundError an der Quelle verhindert. So verhält sich der Code in jeder Umgebung gleich.

Warum tritt ModuleNotFoundError in Docker und CI auf?

Ein ModuleNotFoundError im Container hat einen einfachen Grund. Diese Umgebungen starten bei null. Jedes Paket, das Sie auf Ihrem Rechner von Hand installiert haben, fehlt im Image oder auf dem CI Runner. Deshalb kann lokal funktionierender Code zur Laufzeit scheitern. Meist ist die Requirements Datei unvollständig.

• Die Requirements Datei ist veraltet, ein neues Paket steht nicht darin.
• Der Installationsschritt läuft in der falschen Reihenfolge zum Kopieren des Codes.
• Ein Image enthält mehr als ein Python, und der Befehl ruft ein anderes auf.
• Ein anderes Arbeitsverzeichnis führt dazu, dass Projektimporte fehlen.
• Schließlich stellt der CI Cache eine alte Umgebung wieder her.

Zur Lösung schreiben Sie Ihre Anforderungen mit python -m pip freeze > requirements.txt in eine Datei. Danach führen Sie im Image python -m pip install -r requirements.txt aus. Sind Container neu für Sie, erklärt unser Leitfaden zu Docker Containern die Grundlagen.

Hinweis: Prüfen Sie aus Sicherheitsgründen Ihre Requirements Dateien und installieren Sie Pakete nur aus Quellen, die Sie kennen.

Wie lesen Sie die Tabelle mit Symptom, Ursache und Lösung?

Die Tabelle verknüpft das Symptom, das Sie sehen, mit einer wahrscheinlichen Ursache und einem ersten Lösungsschritt. Die wahrscheinlichste Ursache steht oben.

Warum scheitert der Import trotz erfolgreicher Installation?

Dieser ModuleNotFoundError verwirrt, hat aber wenige Ursachen. Die Ausgabe der Installation meldet Erfolg, pip show listet das Paket, und der Import scheitert trotzdem. Schließen Sie diese drei Möglichkeiten der Reihe nach aus.

• Die Umgebung, in die Sie installiert haben, ist eine andere als die, die den Code startet.
• Die laufende Sitzung begann vor der Installation, etwa weil ein Notebook nicht neu gestartet wurde.
• Eine lokale Datei mit gleichem Namen überdeckt das Paket.

Prüfen Sie danach, ob das installierte Paket überhaupt ein importierbares Modul anbietet. Manche Distributionen installieren nur ein Kommandozeilenwerkzeug. Die offizielle Dokumentation des Pakets sagt das ausdrücklich.

Prüfen Sie schließlich Caches und Überreste. Ein halb gelöschter Ordner einer alten Installation kann die neue überdecken. Eine saubere neue Umgebung schließt diese Möglichkeit endgültig aus.

Können Python Version oder Installationsart das Paket verstecken?

Manchmal wird ein Paket installiert, doch das aktive Python kann es nicht laden. Die vom Paket unterstützte Python Version passt womöglich nicht zu Ihrer. Dann warnt pip meist schon bei der Installation, aber die Warnung geht in der Terminalausgabe leicht unter.

Lesen Sie die Ausgabe der Installation von oben nach unten. Eine Erfolgsmeldung und ein Teilfehler können in derselben Ausgabe stehen, daher reicht ein Blick auf die letzte Zeile nicht. Die offizielle Versionsunterstützung finden Sie auf der Seite des jeweiligen Pakets. Versionsnummern nennen wir hier nicht, weil sich diese Angaben oft ändern.

Eine weitere Möglichkeit ist die Installation für einen einzelnen Benutzer. Blockiert ein Rechteproblem die Installation, legen manche Systeme das Paket in einen benutzerbezogenen Ordner. Eine virtuelle Umgebung beseitigt diese Verwirrung, da sie in ihren eigenen Ordner schreibt.

Was ändert sich bei Conda oder einem anderen Paketmanager?

Werkzeuge wie Conda bringen eigene Umgebungen und eigene Python Installationen mit. In so einer Umgebung können pip und conda dasselbe Paket an verschiedene Orte installieren. Folglich taucht das Paket doppelt auf, aber die aktive Umgebung nutzt nur eines davon.

Die Regel ist einfach: Wählen Sie pro Umgebung einen Hauptmanager. Versuchen Sie, das Paket zuerst mit diesem Manager zu installieren. Ist es dort nicht verfügbar, rufen Sie pip innerhalb derselben Umgebung auf, und zwar in der Form python -m pip. So installieren die beiden Systeme nicht aneinander vorbei.

Ist Ihre Umgebung schon verheddert, ist eine neue Umgebung mit Neuinstallation aus der Requirements Datei der sauberste Weg. Das dauert wenige Minuten und kostet weniger als stundenlanges Raten.

Warum zeigt sich ModuleNotFoundError nur in Tests?

Ein ModuleNotFoundError in Tests hat eine einfache Ursache. Testwerkzeuge nutzen ihr eigenes Arbeitsverzeichnis und eigene Importregeln. Ihr Code läuft in der Anwendung vielleicht einwandfrei, während im Test Ihr eigenes Modul fehlt. Die Testdatei liegt in einem anderen Ordner, und der Projektstamm gelangte nie in den Importpfad.

Beispielszenario: Eine Datei im Ordner tests importiert das Paket app, doch der Projektstamm liegt nicht im Pfad. Das Projekt im Entwicklungsmodus zu installieren, ist die sauberste Lösung. Dann findet man das Paket überall unter demselben Namen, und eine Pfadkorrektur entfällt.

Auch die Konfigurationsdatei des Testwerkzeugs kann Pfade ergänzen. Nutzen Sie das nur, wenn die Projektstruktur es wirklich verlangt. Sonst verschwindet das Problem nur scheinbar und kehrt in der CI in anderer Form zurück.

Wie unterscheiden Sie den Fehler von ImportError und Ähnlichem?

Der Klassenname am Anfang der Meldung weist den Weg. ModuleNotFoundError sagt, dass das Modul gar nicht gefunden wurde. ImportError sagt, dass das Modul zwar gefunden wurde, der gewünschte Name daraus aber nicht lieferbar ist. Die Lösungen unterscheiden sich.

• ModuleNotFoundError: Das Modul liegt nicht im Pfad, also prüfen Sie Installation, Umgebung oder Dateistruktur.
• ImportError (cannot import name): Das Modul existiert, der Name nicht, was auf eine Versionsabweichung oder einen zirkulären Import hindeutet.
• AttributeError: Das Modul wurde geladen, doch das Attribut fehlt, oft ein Zeichen für Überdeckung.
• pip Abhängigkeitskonflikt: Er entsteht bei der Installation, nicht beim Import.

Lesen Sie also zuerst den Klassennamen und springen Sie dann zum passenden Abschnitt. Bei zirkulären Importen kann die Meldung in die Irre führen. Importieren sich zwei Module gegenseitig, sehen Sie ImportError statt ModuleNotFoundError. Die Wurzel bleibt die Struktur, und Sie lösen sie, indem Sie gemeinsamen Code in ein drittes Modul verlagern.

Was ändert sich auf einem Server oder einem entfernten Rechner?

Auf einem Server unterscheiden sich die Python Version, die installierten Pakete und die Umgebungsvariablen von Ihrem Computer. Kopieren Sie Code hinüber und starten ihn, kann ein lokal funktionierender Import scheitern. Prüfen Sie zuerst, welches Python auf dem Server aufgerufen wird.

Haben Sie beim Verbinden mit dem entfernten Rechner Anmeldeprobleme, lesen Sie unseren separaten Beitrag zum SSH Fehler Permission denied (publickey). Geplante Aufgaben und Dienste laufen zudem in einer anderen Umgebung. Dienste erben Ihre aktive Umgebung nicht automatisch, daher geben Sie den vollständigen Pfad zum Python an.

Ähnliche Umgebungsprobleme sehen Sie auch bei Node.js. Unsere Anleitung zum npm ERESOLVE Fehler behandelt Abhängigkeitskonflikte, und der Beitrag zum JavaScript Heap Fehler die Speichergrenze.

Welche Gewohnheiten verhindern den Fehler dauerhaft?

Den Fehler einmal zu beheben, reicht nicht, denn Sie wollen seine Rückkehr verhindern. Die folgenden Gewohnheiten empfiehlt unser Team in der Praxis am häufigsten.

1. Legen Sie für jedes Projekt eine eigene virtuelle Umgebung an und installieren Sie nie in das System Python.
2. Installieren Sie Pakete immer mit python -m pip.
3. Halten Sie Abhängigkeiten in einer Requirements Datei und aktualisieren Sie diese nach jedem neuen Paket.
4. Benennen Sie Dateien nie nach Modulen der Standardbibliothek.
5. Starten Sie Ihr Projekt aus dem Stamm mit -m.
6. Binden Sie Editor und Notebook fest an die Umgebung des Projekts.
7. Nennen Sie die Python Version in Docker und CI Skripten ausdrücklich.

Diese sieben Gewohnheiten verhindern die meisten ModuleNotFoundError Fälle, die wir sehen. Das ist eine Beobachtung aus Erfahrung und keine Statistik. Nutzen Sie Git, halten Sie den Umgebungsordner aus der Versionskontrolle heraus und committen Sie nur die Requirements Datei. Die Grundbefehle finden Sie in unserer Anleitung zu Git und GitHub.

Welche Checkliste nutzen Sie bei der Diagnose?

Wenn Sie nicht weiterkommen, gehen Sie die folgende Liste von oben nach unten durch. Jeder Punkt hat die Antwort ja oder nein.

• Haben Sie den Modulnamen richtig geschrieben, auch in Groß und Kleinschreibung?
• Gehören das laufende Python und pip zum selben Interpreter?
• Ist die virtuelle Umgebung aktiv?
• Nutzen Editor und Notebook dieselbe Umgebung?
• Passt der Installationsname zum Importnamen?
• Liegt im Ordner eine Datei mit dem Namen des Moduls?
• Starten Sie den Code aus dem Projektstamm?
• Ist die Requirements Datei für Docker oder CI aktuell?

Wir empfehlen, die Liste auszudrucken und neben den Schreibtisch zu legen. ModuleNotFoundError kehrt meist aus denselben wenigen Gründen zurück. Wird die Checkliste zur Gewohnheit, lösen Sie das Problem daher in Minuten. Müssen Sie Serverprotokolle lesen, hilft unsere kostenlose Logfile Analyse.

Welche Angaben sammeln Sie, wenn der Fehler bleibt?

Bitten Sie jemanden um Hilfe, beschleunigen vollständige Angaben die Antwort. Mit den folgenden Informationen lässt sich das Problem in wenigen Minuten diagnostizieren.

1. Kopieren Sie den gesamten Traceback ohne Kürzung.
2. Schreiben Sie den Befehl und den Ordner, aus dem Sie ihn gestartet haben.
3. Fügen Sie die Ausgabe von python -c "import sys; print(sys.executable)" hinzu.
4. Fügen Sie die Ausgabe von python -m pip --version hinzu.
5. Nennen Sie, ob Sie virtuelle Umgebung, Docker, CI oder Notebook nutzen.
6. Teilen Sie eine kurze Baumansicht des Projektordners.

Diese Angaben sollten keine persönlichen Daten enthalten. Entfernen Sie vor dem Teilen Benutzernamen aus Pfaden und geheime Schlüssel. Teilen Sie außerdem nur den kleinsten Code, der den Fehler reproduziert. Das erleichtert das Lesen und verhindert, dass Geheimnisse nach außen gelangen.

Möchten Sie die Umgebungsverwaltung Ihres Projekts gemeinsam aufsetzen?

Ist der Fehler einmalig, genügen die obigen Schritte. Hat jedoch jede Person im Team einen anderen Rechner, kostet die uneinheitliche Umgebung dauerhaft Zeit. Dann sollten Sie Abhängigkeitsverwaltung, Einrichtungsskripte und Auslieferungsschritte gemeinsam ordnen.

Für solche Arbeit bieten Talha Aslan und Team individuelle Softwareentwicklung an. Schildern Sie Ihr Projekt und fordern Sie auf unserer Seite zur individuellen Softwareentwicklung ein Angebot an. Den Umfang legen wir gemeinsam nach Ihrem Projekt fest. Wir versprechen kein bestimmtes Ergebnis, führen Diagnose und Einrichtung aber in geordneter Reihenfolge durch.