oder Profi vs. Bastler

Nach über einem Jahrzehnt musste ich meine Webcam neu aufsetzen. Der USB Speicherstick, auf dem die /root Partition lief, war verschlissen und unzuverlässig geworden. Immerhin – gut 12 Jahre hat er problemlos durchgehalten und dabei über 200.000 Aufnahmen verarbeitet. Die alte Webcam lief auf Raspbian Jessie – inzwischen komplett veraltet und aus der Wartung gefallen – Updates gibt es nicht mehr. Dasselbe Problem mit Python – bisher lief die Cam noch mit dem seligen Python 2.7.

Die Migration auf eine neue OS Version und einen neuen Python Interpreter ist kein Zuckerschlecken! Den Umgang mit einem wesentlichen Fallstrick zeige ich euch im Folgenden:

Migrationswehen

Also frisch ans Werk und mit Raspbian Bookworm und Python 3.x losgelegt. Praktisch alle Libraries waren veraltet und mussten neu installiert werden. Python 3.x hat auch stellenweise eine andere Syntax.

Die neue picamera2 Library ist grottig dokumentiert – das ist aber ein anderes Kapitel.

Ärgerlich wurde es bei der Installation von nicht zum Debian Kernel gehörenden Python Libraries wie der für den Luftdruck-, Temperatur-, Luftfeuchtigkeitssensor BME280:

Solltet ihr mit Raspberry Pi OS in der Version Bookworm arbeiten, wird der übliche Installationsbefehl für den BME280 fehlschlagen. Normalerweise wird der mit

sudo pip install RPI.BME280

installiert. Stattdessen gibt es einen Fehler der Art

510 error: externally managed environment

Das bedeutet im Grunde, neue Python Libraries aus anderen Quellen müssen in einer virtuellen Umgebung installiert werden. Dieser Fakt wird meistens nur apodiktisch postuliert: "Man macht das jetzt eben so!"

Es liegt wohl daran, dass einerseits Debian-hauseigene Komponenten bzw. Python Libraries mit sudo apt install python3-irgendEineLibrary  installiert werden, "fremde", also nicht zum Kernel gehörende, Python Libraries mit  sudo pip install irgendEineAndereLibrary .

apt und pip sind zwei verschiedene Paketverwaltungen, die nur ihre eigenen Abhängigkeiten (d.h. dazu gehörende Unterkomponenten) kennen. So kann es unter Umständen sein, dass pip igendwelche Komponenten zerschießt, die apt vorher installiert hat.

<begin rant> Man hätte natürlich bei der Weiterentwicklung von Debian und Python, den pip Paketmanager in die Abhängigkeiten von apt hineinschauen lassen können und vice versa. Aus meiner beruflichen Erfahrung weiß ich jedoch, dass SW Entwickler nichts so sehr hassen, wie sich mit Anderen abzustimmen – viel zu viel Aufwand, den man nicht bezahlt bekommt. Also anstatt das Gute zu tun, wird der Nutzer mit dem Python Enhancement Proposal 668 (PEP668) überzogen. Was für ein Bockmist! <end rant>

Overengineered?

Bei meinem Pi handelt es sich um einen Single User Server – der User bin ich und installiere als Einziger irgendwelche Libraries, Module, Treiber etc. Dazu kommt meist noch ein ein Maschinenuser (Programm wird aufgerufen und läuft) oder der Webserver. Es besteht also meines Erachtens nur eine geringe Gefahr dass ich Anderen etwas durch die Installation von Python Libraries zerschieße. Bei größeren Multiuser (Entwicklungs-)Servern oder mit mächtigen Python-Applikationen bestückten Servern macht es sicher Sinn, die einzelnen vom Root User installierten Komponenten voneinander zu trennen. Bei einem Raspberry Pi als Bastelrechner imho nicht!

Wer will, kann sich natürlich intensiver mit dem Python Virtual Environment beschäftigen – ich lasse es für den Zweck meines Blogs sein und zeige lieber auf, wie man diese Verkomplizierung umgeht. Profi SW Entwickler mögen mir verzeihen oder mir genau erklären, warum ich Python virtualisieren sollte.

Die beste Erklärung bzw. Anleitung findet sich bei  piMyLifeUp aber auch bei Stackoverflow, dort steht auch, wie man mit der virtuellen Umgebung umgeht. Aber hier wollen wir ja das Gegenteil davon.

Der Quick & Dirty Ansatz für risikofreudige Hobbyisten

Beachtet dennoch folgenden Hinweis von Stackoverflow:

"If you have considered your options carefully and are still sure that you want to install packages "system-wide" and risk breaking your system (for example, by overwriting libraries that were part of tools written in Python that came with your system), Pip needs to be given permission to do so."

Für risikofreudige Bastler wird die Library wird dann wie folgt installieren:

sudo pip install RPI.BME280 --break-system-packages

Python kann dann nach wie vor direkt von der Shell aus aufgerufen werden – ohne irgendwelche Klimmzüge wie ich sie in meinem Beitrag über den Optolink Splitter beschrieben habe.

Keine Angst! Wahrscheinlichkeit, etwas kaputt zu machen ist ziemlich gering…