Mein „Crash“ gestern Abend hatte ja die Ursache, dass ich pip unter meiner Python-Installation vermisst und dann ein paar „destruktive“ Ansätze zur Lösung versucht habe. Heute morgen habe ich dann das Problem beseitigt, wobei ich gerne zugebe, dass ChatGPT wieder unterstützt hat. Wobei man die richtigen Fragen stellen und die Antworten als auch Fehlermeldungen und Ausgaben vernünftig verstehen und Tipps anpassen muss (was ich als meine Eigenleistung sehe). Gestern habe ich ja erfahren, was ein blindes Verwenden von Vorschlägen bedeutet. Doch als Spoiler zuerst meine beiden Lösungen, worüber ich pip jetzt verwenden kann, um fehlende Module wie pandas, numpy, matplotlib etc. auf meinem Linux Mint 22 zu installieren:
- pipx
- Eine virtuelle Umgebung
- Eine alternative Python-Installation wie zusätzliches CPython oder IronPython nutzen
Die Frage, ob ich nicht bis 3 zählen kann, weil ich von „beiden“ Lösungen rede, soll in der Antwort münden, dass ich die ersten beiden ausprobiert habe und die mir vollständig genügen.
Doch erst einmal die Ursache für mein Problem. Ich habe pip bzw. pip3 erst einmal nicht gefunden und dann trotz verschiedener Aufrufanweisungen nicht ausführen können. Der Ausgangsfehler war im Prinzip die Fehlermeldung:
error: externally-managed-environment
× This environment is externally managed
Irgendwann hatte ich diese eigentlich sehr aussagekräftige Fehlermeldung auch endlich mal verstanden. Der Fehler tritt auf, weil unter meinem Linux-System mein Python-Umfeld als „extern verwaltet“ betrachtet wird und das darin resultiert, dass das System den direkten Einsatz von pip für die Installation von Paketen in der globalen Python-Umgebung nicht zulässt.
Was letztendlich auch erklärt, warum alle vorherigen Aktionen ins Leere gelaufen sind und vollkommen an der falschen Stelle gegraben haben:
Neue Installation von pip für Python 3.12:
sudo apt update sudo apt install python3-pip
Oder:
wget https://bootstrap.pypa.io/get-pip.py python3.12 get-pip.py
Kam nur raus, dass alles schon korrekt installiert ist. Klar – Fehlermeldung lesen und vor allen Dingen verstehen hilft, aber das habe erst einmal nicht.
Überprüfen der Installation
python3.12 -m pip --version echo $PATH which pip3 whereis pip
Alles toll, führt nur (natürlich, wenn man die Lösung kennt) nicht weiter. Das führte bei mir nur zu Erfolgsmeldungen, die aber nutzlos waren. Ich kam mir an die Situation erinnert, wenn ich nach meinem Sohn rufe und er „GLEICH“ sagt. Was in keiner Weise weiterbringt.
Ein bisschen weiter zum Heben der Scheuklappen bei mir hat aber die Verwendung der Ausgabe von which pip3 (/home/ralph/.local/bin/pip3) dann schon geführt, denn der Aufruf /home/ralph/.local/bin/pip3 resultierte in dem Fehler:
home/ralph/.local/bin/pip3: kann nicht ausführen: benötigte Datei nicht gefunden
Auch dass ich pip 24.0 in /usr/lib/python3/dist-packages/pip (python 3.12) entdeckt hatte, war zwar auch erst einmal eine weitere Sackgasse. Aber die zwei Vorgehensweisen haben dann wie erwähnt zum Ziel geführt, weil es mir endlich wie Schuppen von den Augen gefallen ist. Diese anfängliche Fehlermeldung hat alles beinhaltet, was man wissen musste. Nur halt auch sehen und verstehen. Die Sache mit dem Wald und den Bäumen.
Verwendung von virtuellen Umgebungen
Eine der besten Methoden zur Paketinstallation ist die Verwendung einer virtuellen Umgebung. So kann man Pakete unabhängig vom System installieren, wobei ich auch da erst einmal auf einen dummen Fehler gelaufen bin. Grundsätzlich geht das so:
Erstellen einer virtuellen Umgebung:
python3.12 -m venv mein_venv
Aktivieren der virtuellen Umgebung:
source mein_venv/bin/activate
Machen, was man da machen will. Etwa Installieren von Paketen mit pip:
pip install ...
Deaktivieren der virtuellen Umgebung:
deactivate
Die Einrichtung der virtuellen Umgebung resultierte jedoch bei mir erst einmal in einem Fehler, den ich ebenso erst nach und nach verstanden habe. Es war ein Permission denied – Fehler. Ich konnte die virtuelle Umgebung nicht in einem Verzeichnis erstellen, für das ich keine Schreibrechte hatte und der Wechsel auf sudo hat Folgeprobleme gemacht. Das Erstellen im Home-Verzeichnis (cd ~) war dann problemlos möglich und ist so naheliegend, dass es schon weh tut.
Verwendung von pipx
Nun hätte ich mir auch die vielen Irrwege samt des Crashs gestern ersparen können, wenn ich von Anfang an die Fehlermeldungen genauer gelesen und eben auch verstanden hätte. Wie so oft hat da ja schon der eigentlichen Lösungsweg dringesteckt. Wenn man auf einem System wie Mint Linux Anwendungen installieren möchte, die nicht in Debian-Paketen verfügbar sind, ist pipx die Lösung, auf die eben sogar schon in der Fehlermeldung verwiesen wird. pipx verwaltet Anwendungen in isolierten Umgebungen.
Installieren pipx (falls noch nicht installiert):
sudo apt install pipx
Dann geht das Installieren eines Pakets mit pipx wie mit pip:
pipx install ...
Was ist nun besser?
Wenn ich die mit pip installierten Pakete in einer virtuellen Umgebung nutzen will, muss ich immer die virtuelle Umgebung nutzen.
source mein_venv/bin/activate
Solange die virtuelle Umgebung aktiviert ist, kann man die Pakete ganz normal verwenden.
Mit pipx installierte Pakete sind systemweit verfügbar, ohne dass man eine spezielle Umgebung aktivieren muss. pipx sorgt dafür, dass die Anwendungen in isolierten Umgebungen laufen, sodass es keine Konflikte mit anderen Python-Paketen gibt.
Beide Varianten haben Charme und ich werde wohl von Fall zu Fall entscheiden.