Positron 2026.10.2-3 findet den Python-Interpreter nicht? Was tun? 2026

Die offiziellen Positron-Release Notes führen die Version 2026.10.2-3 als den hier behandelten Versionsstand. Symptom → schnellster Ansatz: Ist die Interpreterliste leer, prüfen Sie zuerst den geöffneten Projektordner und die Erkennungsregeln. Ist ein Interpreter sichtbar, aber der Start scheitert, kontrollieren Sie den vollständigen Interpreterpfad und die Sitzungsmeldung, bevor Sie Positron neu installieren oder die Umgebung neu erstellen.

Dieser Leitfaden richtet sich an Forschende, bei denen ein Python-Projekt in Positron keinen Interpreter anzeigt oder die falsche Umgebung auswählt.
Er hilft auch bei Sitzungsfehlern sowie bei uv-, venv- oder conda-Umgebungen, die nach einem Neustart scheinbar verschwunden sind.
Wer Positron über einen entfernten Mac verwendet, kann außerdem prüfen, ob der gewählte Verbindungsweg tatsächlich unterstützt wird.

Zuletzt aktualisiert am 02.11.2026; Versionsstand und Funktionsgrenzen anhand der Positron-Release Notes sowie der offiziellen Dokumentation zur Python-Erkennung und zu Remote SSH geprüft. Neue Releases oder geänderte Dokumentation können einzelne Menübezeichnungen und Funktionsgrenzen verändern.

Positron 2026.10.2-3: Python-Interpreter nicht gefunden – zuerst die Fehlerart bestimmen

„Interpreter nicht gefunden“ beschreibt nicht zwingend einen einzigen Fehler. Eine leere Auswahlliste weist zunächst auf ein Erkennungs- oder Projektproblem hin. Ein ausgewählter Interpreter mit falschem Pfad ist dagegen ein Auswahlproblem. Wenn die Auswahl stimmt, aber keine Sitzung startet, liegt die Ursache möglicherweise beim Ausführen des Interpreters, bei einer erforderlichen Sitzungskomponente oder bei der Projektkonfiguration.

Diese Trennung ist wichtig, weil die sichtbaren Symptome unterschiedliche Belege liefern. Ein Importfehler bei einem einzelnen Paket beweist beispielsweise nicht, dass Positron den Interpreter nicht erkennt. Ebenso zeigt eine leere Liste nicht, ob eine bereits vorhandene Umgebung beschädigt ist: Sie kann außerhalb des berücksichtigten Suchbereichs liegen oder durch eine Erkennungsregel verborgen werden. Positron beschreibt Erkennung und Verwaltung von Python-Umgebungen in der Dokumentation zu Python-Installationen und zur Interpreterverwaltung.

Beobachtung in Positron	Wahrscheinliche Prüfrichtung	Nächster risikoarmer Schritt
Die Interpreterliste ist leer	Projektordner, Erkennungsbereich und Filterregeln	Projektpfad bestätigen und Erkennung erneut ausführen
Ein Interpreter ist sichtbar, aber unpassend	Vollständiger Pfad und projektbezogene Auswahl	Den tatsächlich angezeigten Pfad mit der Projektumgebung vergleichen
Die Auswahl stimmt, die Sitzung startet aber nicht	Ausführbarkeit, Sitzungsstartmeldung und Projektkonfiguration	Denselben Interpreter im Terminal testen und die Meldung sichern
Nur ein Paketimport schlägt fehl	Abhängigkeiten oder Installationszustand des Projekts	Importfehler getrennt von der Interpretererkennung untersuchen

Behandeln Sie diese Beobachtungen als Diagnosehinweise, nicht als Beweis für eine bestimmte Ursache. Ein GitHub-Einzelfall oder ein Bericht einer anderen Person wäre kein Nachweis für einen allgemeinen Fehler in der genannten Positron-Version; deshalb stützt sich die folgende Prüfung auf die lokal sichtbaren Pfade und Meldungen.

Leere Liste: Positron Python-Umgebung im Projekt erneut entdecken

Wenn eine bereits erstellte Umgebung fehlt, beginnen Sie nicht mit einer Neuinstallation von Python. Stellen Sie zunächst fest, wo Positron sucht und welcher Ordner als Projekt geöffnet ist. Die Auswahl eines übergeordneten Verzeichnisses, eines einzelnen Skripts oder eines anderen Projektordners kann dazu führen, dass eine projektlokale Umgebung nicht dort auftaucht, wo Sie sie erwarten.

Schritt 1: Geöffneten Projektordner mit dem erwarteten Pfad abgleichen

Prüfen Sie den Projektnamen und den vollständigen Pfad im Positron-Fenster. Vergleichen Sie ihn mit dem Verzeichnis, in dem die Projektdateien und die Python-Umgebung liegen. Bei einem Forschungsprojekt kann eine Arbeitskopie neben einem synchronisierten oder archivierten Ordner existieren; kontrollieren Sie deshalb, ob tatsächlich die Arbeitskopie geöffnet ist, die Sie bearbeiten möchten.

Suchen Sie anschließend nach dem Verzeichnis der Umgebung, ohne es zu verschieben oder zu löschen. Bei einer lokalen venv-Umgebung liegt es häufig innerhalb oder in unmittelbarer Nähe des Projekts; bei anderen Einrichtungsweisen kann der Speicherort abweichen. Entscheidend ist nicht der Name des Ordners, sondern ob der erwartete Python-Pfad dort vorhanden ist.

Schritt 2: Erkennungsregeln auf Ausschlüsse und Überschreibungen prüfen

Öffnen Sie die Positron-Einstellungen und vergleichen Sie die Regeln für die Interpreter-Erkennung mit dem tatsächlichen Speicherort. Achten Sie besonders auf Einträge für include, exclude und override: Ein Ausschluss kann einen Ordner ausblenden, während eine Überschreibung die normale Erkennung auf einen engeren oder abweichenden Bereich lenken kann. Die genaue Bedeutung der Einstellungen und ihre Anwendungsgrenzen sind in der offiziellen Beschreibung zur Python-Umgebungserkennung dokumentiert.

Prüfen Sie dabei die Einstellungen für den Arbeitsbereich und für den Benutzer getrennt. Eine Benutzereinstellung kann für mehrere Projekte gelten; eine arbeitsbereichsbezogene Einstellung kann dagegen nur im geöffneten Projekt wirksam sein. Ändern Sie zunächst nur eine relevante Regel und notieren Sie den vorherigen Wert. So lässt sich später erkennen, welche Änderung die Liste beeinflusst hat, statt mehrere mögliche Ursachen gleichzeitig zu verändern.

Schritt 3: Erkennung aktualisieren und die Änderung festhalten

Verwenden Sie die in Positron verfügbare Aktion zum erneuten Entdecken beziehungsweise Aktualisieren von Python-Umgebungen. Vergleichen Sie danach die Interpreterliste mit dem vorherigen Zustand und notieren Sie, ob der gesuchte Pfad erschienen ist. Falls die Umgebung weiterhin fehlt, bleiben Projektpfad, Speicherort und Filterregeln die aussagekräftigsten Ansatzpunkte; eine wiederholte Aktualisierung allein behebt keinen falschen Suchbereich.

Hinweis: Ändern Sie Erkennungsregeln nicht vorsorglich für alle Projekte. Wenn die Umgebung nur in einem bestimmten Arbeitsbereich fehlt, sollte die Korrektur möglichst auf diesen Bereich begrenzt bleiben.

Falsche Auswahl: Interpreterpfad und Projektbindung kontrollieren

Eine Umgebung kann verfügbar sein, während Positron dennoch den Systeminterpreter oder eine Umgebung aus einem anderen Forschungsprojekt verwendet. Prüfen Sie deshalb nicht nur den angezeigten Namen. Entscheidend ist der vollständige Pfad der ausgewählten Python-Datei und die Frage, ob dieser Pfad noch existiert.

Schritt 4: uv, venv oder conda anhand des ausführbaren Pfads prüfen

Bei einem Projekt mit uv, venv oder conda öffnen Sie die betreffende Umgebung und kontrollieren, ob der erwartete Python-Interpreter an der vorgesehenen Stelle vorhanden ist. Wurde ein Projektverzeichnis verschoben, umbenannt oder neu erstellt, kann ein früher ausgewählter Pfad ins Leere zeigen. In diesem Fall ist die Umgebung nicht zwangsläufig verloren; Positron kann lediglich noch auf einen nicht mehr gültigen Speicherort verweisen.

Wählen Sie anschließend den tatsächlich vorhandenen Interpreter erneut über seine Datei aus. Vergleichen Sie die Pfadangabe in der Auswahl mit dem Ergebnis eines Terminaltests im Projektverzeichnis. Ein kurzer Test kann zum Beispiel die Identität des laufenden Interpreters ausgeben:

python -c "import sys; print(sys.executable)"

Führt der Befehl im Terminal einen anderen Pfad zurück als Positron, ist zunächst die Auswahl oder Projektbindung zu korrigieren. Führt er denselben Pfad zurück, aber eine Sitzung startet trotzdem nicht, wechseln Sie zur Diagnose des Sitzungsstarts, statt die Umgebung erneut anzulegen.

`defaultInterpreterPath` richtig einordnen

Die Einstellung defaultInterpreterPath ist kein zuverlässiger Hebel, um bei jedem Start eine bestehende Auswahl zu überschreiben. Sie dient als Standardpfad im Rahmen der Interpreterkonfiguration; eine Änderung dieser Einstellung ist deshalb kein Beleg dafür, dass der aktuell ausgewählte Interpreter gewechselt wurde. Kontrollieren Sie die tatsächlich angezeigte Auswahl und den vollständigen Pfad, statt dieselbe Einstellung wiederholt zu ändern. Positrons Dokumentation zur Interpreterverwaltung erläutert, wie Interpreter ausgewählt und verwaltet werden.

Wenn eine Umgebung nach einem Neustart scheinbar verschwunden ist, unterscheiden Sie außerdem zwischen zwei Fällen: Ist der Interpreterpfad weiterhin vorhanden, aber die Liste leer, prüfen Sie die Erkennungseinstellungen erneut. Ist der Pfad nicht mehr vorhanden, untersuchen Sie, ob die Umgebung gelöscht, verschoben oder außerhalb des aktuellen Arbeitsverzeichnisses angelegt wurde. Eine neue Umgebung sollte erst erstellt werden, wenn der alte Speicherort und die Projektanforderungen geklärt sind.

Startfehler: Interpreter, Sitzung und Projektproblem getrennt prüfen

Ist der Interpreter auswählbar, aber Positron öffnet keine Python-Sitzung, sammeln Sie zuerst die Meldungen aus dem Sitzungsstart und der Positron-Ausgabe. Die offizielle Anleitung zur Fehlerbehebung und die Hinweise zum Start eines Interpreters helfen, die Diagnose auf den tatsächlichen Fehler einzugrenzen. Notieren Sie den ausgewählten Pfad und die vollständige Fehlermeldung, bevor Sie Einstellungen verändern.

Ein Fehler beim Starten des ausführbaren Interpreters ist anders zu behandeln als ein Problem mit einer Sitzungskomponente. Ein dritter Fall liegt vor, wenn die Sitzung startet, aber beim Öffnen des Projekts ein bestimmter Import fehlschlägt. Letzteres spricht zunächst für eine fehlende oder inkompatible Projektabhängigkeit, nicht automatisch für eine beschädigte Positron-Installation.

Führen Sie denselben Interpreter im Terminal aus dem Projektverzeichnis aus und prüfen Sie, ob sich der Fehler dort wiederholen lässt. Testen Sie danach, sofern möglich, ein leeres oder minimales Projekt mit derselben Auswahl. Startet die Sitzung außerhalb des Forschungsprojekts, aber nicht darin, untersuchen Sie Projektdateien, Startskripte und Arbeitsbereichseinstellungen. Scheitert der Interpretertest bereits im Terminal, prüfen Sie seine Ausführbarkeit und die Umgebung selbst.

Erfahrungsregel: Eine erfolgreiche leere Sitzung bestätigt lediglich, dass Positron eine Sitzung starten konnte. Sie belegt weder, dass alle benötigten Pakete vorhanden sind, noch dass die Forschungsanalyse mit den erwarteten Daten reproduzierbar läuft.

Nach einer Korrektur wiederholen Sie genau den Test, der zuvor scheiterte. Wenn der Fehler ein Paketimport war, testen Sie denselben Import erneut; wenn der Start scheiterte, prüfen Sie die Sitzung erneut mit demselben Interpreterpfad. So vermeiden Sie, einen Fehler an anderer Stelle mit einer Änderung zu überdecken, die für das Projekt keine Aussagekraft hat.

Remote Mac und Remote SSH sind unterschiedliche Arbeitsweisen

Wer Positron auf einem entfernten Mac verwendet, muss zwischen zwei Verbindungsmodellen unterscheiden. Im ersten Modell wird Positron innerhalb der grafischen Sitzung des entfernten Mac ausgeführt; die Oberfläche und die Python-Umgebung laufen dort. Im zweiten Modell bleibt Positron lokal geöffnet und versucht, über Remote SSH mit einem anderen Rechner zu arbeiten. Diese beiden Wege sind nicht gleichbedeutend und haben unterschiedliche Anforderungen.

Die offizielle Positron-Dokumentation zu Remote SSH nennt Linux als erforderliches Betriebssystem des Remote-Hosts. Eine native macOS-Installation wird für diese Remote-SSH-Funktion nicht als unterstützter Host beschrieben. Wenn Ihr Ziel also ist, Positron samt Python-Projekt auf macOS auszuführen, wählen Sie nicht allein aufgrund der Bezeichnung „Remote“ den Remote-SSH-Weg. Starten Sie Positron stattdessen in einer passenden grafischen Mac-Sitzung, sofern diese Arbeitsweise für Ihr Projekt verfügbar ist.

Prüfen Sie vor der Wahl auch, ob macOS fachlich tatsächlich erforderlich ist. Wenn das Projekt auf einem Linux-HPC-System oder lokal auf dem vorhandenen Rechner vollständig unterstützt wird, kann ein zusätzlicher Mac-Zugang unnötig sein. Wenn ein macOS-spezifisches Forschungswerkzeug, eine Plattformprüfung oder eine bestimmte macOS-Abhängigkeit Teil der Arbeit ist, sollte die Umgebung dagegen auf dem System getestet werden, für das sie vorgesehen ist.

Projektkopie prüfen und die passende Umgebung entscheiden

Bevor Sie eine Forschungsumgebung für die eigentliche Arbeit freigeben, testen Sie eine Kopie des Projekts ohne sensible Daten. Prüfen Sie nacheinander den Interpreterpfad, einen für das Projekt wichtigen Paketimport und eine repräsentative Arbeitsoperation. Halten Sie fest, welcher Interpreter verwendet wurde, welche Abhängigkeiten für den Test benötigt wurden und ob die Operation das erwartete Ergebnis erzeugte. Das ist aussagekräftiger als die bloße Feststellung, dass Positron geöffnet werden konnte.

Bei Forschungsdaten gelten zusätzlich die Vorgaben Ihrer Hochschule oder Einrichtung. Übertragen Sie keine personenbezogenen, vertraulichen oder anderweitig geschützten Daten in eine entfernte Umgebung, bevor Datenzugriff, Speicherort und zulässiger Übertragungsweg geklärt sind. Ein erfolgreich gestarteter Remote Desktop bestätigt weder die Eignung für sensible Daten noch eine institutionelle Freigabe. Trennen Sie daher die technische Prüfung mit einer bereinigten Projektkopie von der späteren Entscheidung über produktive Daten.

Entscheidung nach konkretem Bedarf

Wenn das Projekt mit dem lokalen System oder der vorhandenen Linux-Umgebung zuverlässig läuft und keine macOS-spezifische Abhängigkeit hat, dann bleiben Sie bei dieser Umgebung und dokumentieren Sie Interpreterpfad und Abhängigkeiten.
Wenn Positron den vorhandenen Interpreter lediglich nicht entdeckt, dann korrigieren Sie Projektordner oder Erkennungsregeln und wählen Sie erst danach den bestätigten Pfad.
Wenn die Auswahl stimmt, aber die Sitzung scheitert, dann vergleichen Sie Terminaltest, Positron-Ausgabe und ein minimales Projekt, bevor Sie die Umgebung neu erstellen.
Wenn die Forschungssoftware oder die Abnahme tatsächlich macOS voraussetzt und im Labor kein geeigneter Mac verfügbar ist, dann prüfen Sie eine grafische Remote-Mac-Arbeitsweise mit einer bereinigten Projektkopie. Einen ersten Überblick über die verfügbaren Möglichkeiten erhalten Sie in der VNCMac-Übersicht zu Remote-Mac-Angeboten; die konkreten Mietoptionen sind auf der Seite zum Mieten eines Mac in der Cloud beschrieben.
Wenn Ihre lokale Positron-Installation per Remote SSH auf einen Mac zugreifen soll, dann ändern Sie den Verbindungsweg: Die dokumentierte Remote-SSH-Funktion setzt einen Linux-Remote-Host voraus.

Bei einem Remote-Mac-Test sollten Sie Stabilität und Datenschutz nicht aus der ersten erfolgreichen Sitzung ableiten. Prüfen Sie, ob die Verbindung für die benötigten Arbeitsabschnitte verfügbar ist, wie Sie Dateien übergeben und ob die Hochschulregeln den geplanten Zugriff erlauben. Eine Remote-Umgebung ist außerdem nicht automatisch die beste Wahl für dauerhaft hohe Rechenlast, benötigte physische Anschlüsse oder sensible Daten, die Ihre Einrichtung nicht extern verarbeiten lassen darf.

Im Vergleich zu einem passenden Mac vor Ort fehlen einer bestehenden Windows- oder Linux-Arbeitsumgebung bei einem macOS-spezifischen Projekt möglicherweise die Zielplattform, eine kompatible grafische Anwendung und eine verlässliche Möglichkeit, genau diese Umgebung zu reproduzieren. Ein Remote Mac ist dann eine prüfbare Alternative, ersetzt aber weder die institutionelle Datenschutzfreigabe noch die Abnahme des konkreten Projekts. Wenn Sie nur zeitweise macOS-Kompatibilität oder eine grafische Positron-Sitzung benötigen und im Labor kein geeignetes Gerät verfügbar ist, kann die Anmietung eines Mac von VNCMac den Test ermöglichen, ohne dass Sie dafür sofort eigene Hardware anschaffen müssen. Prüfen Sie vor dem Einsatz mit einer bereinigten Projektkopie, ob Interpreter, benötigte Pakete und repräsentative Forschungsoperationen in Ihrer geplanten Arbeitsweise funktionieren.