Nach \u00fcber einem Jahrzehnt musste ich meine Webcam neu aufsetzen. Der USB Speicherstick, auf dem die \/root Partition lief, war verschlissen und unzuverl\u00e4ssig geworden. Immerhin – gut 12 Jahre hat er problemlos durchgehalten und dabei \u00fcber 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.<\/p>\n
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:<\/p>\n
<\/p>\n
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.<\/p>\n
Die neue picamera2 Library ist grottig dokumentiert – das ist aber ein anderes Kapitel.<\/p>\n
\u00c4rgerlich wurde es bei der Installation von nicht zum Debian Kernel geh\u00f6renden Python Libraries wie der f\u00fcr den Luftdruck-, Temperatur-, Luftfeuchtigkeitssensor BME280<\/strong>:<\/p>\n Solltet ihr mit Raspberry Pi OS in der Version Bookworm oder sp\u00e4ter arbeiten, wird der \u00fcbliche Installationsbefehl f\u00fcr den BME280 fehlschlagen. Normalerweise wird der mit<\/p>\n sudo pip install RPI.BME280<\/span><\/p>\n installiert. Stattdessen gibt es einen Fehler der Art<\/p>\n 510 error<\/span>: externally managed environment<\/p>\n Das bedeutet im Grunde, neue Python Libraries aus anderen Quellen m\u00fcssen in einer virtuellen Umgebung installiert<\/strong> werden. Dieser Fakt wird meistens nur apodiktisch postuliert: \"Man macht das jetzt eben so!\"<\/p>\n Es liegt wohl daran, dass einerseits Debian-hauseigene Komponenten bzw. Python Libraries mit sudo apt install python3-irgendEineLibrary<\/span>\u00a0 installiert werden, \"fremde\", also nicht zum Kernel geh\u00f6rende, Python Libraries mit\u00a0 sudo pip install irgendEineAndereLibrary<\/span>\u00a0.<\/p>\n apt<\/strong> und pip<\/strong> sind zwei verschiedene Paketverwaltungen, die nur ihre eigenen Abh\u00e4ngigkeiten (d.h. dazu geh\u00f6rende Unterkomponenten) kennen. So kann es unter Umst\u00e4nden sein, dass pip igendwelche Komponenten zerschie\u00dft, die apt vorher installiert hat oder zum Standard Installationsumfang der Distribution geh\u00f6ren.<\/p>\n <rant> Man h\u00e4tte nat\u00fcrlich bei der Weiterentwicklung von Debian und Python, den pip Paketmanager in die Abh\u00e4ngigkeiten von apt hineinschauen lassen k\u00f6nnen und vice versa. Aus meiner beruflichen Erfahrung wei\u00df 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<\/span><\/a>) \u00fcberzogen. Was f\u00fcr ein Bockmist! <\/rant><\/span><\/p>\n Und nicht nur das, dein Python Programm muss hinterher jedes Mal umst\u00e4ndlich in der virtuellen Umgebung gestartet und betrieben werden. Wenn ich eine virtuelle Umgebung gewollt h\u00e4tte, w\u00e4re ich auf Docker o.\u00e4. umgestiegen.<\/p>\n Bei meinem Pi handelt es sich um einen Single User Server \u2013 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\u00e4uft) oder der Webserver. Es besteht also meines Erachtens nur eine geringe Gefahr dass ich Anderen etwas durch die Installation von Python Libraries zerschie\u00dfe. Bei gr\u00f6\u00dferen Multiuser (Entwicklungs-)Servern oder mit m\u00e4chtigen Python-Applikationen best\u00fcckten Servern macht es sicher Sinn, die einzelnen vom Root User installierten Komponenten voneinander zu trennen. Bei einem Raspberry Pi als Bastelrechner imho nicht! Debian (Raspberry Pi OS) scheint auch weniger empfindlich zu sein. Ich habe geh\u00f6rt, dass pip bei Fedora Distributionen z.B. wesentlich kritischer ist.<\/p>\n Wer will, kann sich nat\u00fcrlich intensiver mit dem Python Virtual Environment besch\u00e4ftigen \u2013 ich lasse es f\u00fcr den Zweck meines Blogs sein und zeige lieber auf, wie man diese Verkomplizierung umgeht. Profi SW Entwickler m\u00f6gen mir verzeihen oder mir genau erkl\u00e4ren, warum ich Python unter Debian\/Raspbian\u00a0 virtualisieren sollte.<\/p>\n Gute Erkl\u00e4rungen bzw. Anleitungen finden sich bei\u00a0 piMyLifeUp<\/a> aber auch bei Stackoverflow<\/a>, dort steht auch, wie man mit der virtuellen Umgebung umgeht. Aber hier wollen wir ja das Gegenteil davon.<\/p>\n Will man beispielsweise die MQTT Library paho-mqtt <\/em>installieren, sagen einem die meisten Tutorials, man m\u00f6ge das mitsudo pip3 install paho-mqtt<\/span>\u00a0 installieren. Es geht aber auch \u00fcber apt: sudo apt install python3-paho-mqtt <\/span>\u00a0und man hat die oben beschriebenen Probleme nicht.<\/p>\n Also im Zweifelsfall erst einmal mit apt<\/em> probieren. Die Libraries sind ggf. nicht am bleeding edge of the development<\/em> aber in der Regel v\u00f6llig ausreichend.<\/p>\n Beachtet dennoch folgenden Hinweis von Stackoverflow:<\/p>\n \"If you have considered your options carefully and are still sure that you want to install packages \"system-wide\" and risk breaking your system<\/strong> (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.\"<\/em><\/p>\n Der risikofreudige Bastler wird die Library dann wie folgt installieren:<\/p>\n sudo pip install RPI.BME280 –break-system-packages<\/span><\/p>\n Python kann dann nach wie vor direkt von der Shell aus aufgerufen werden – ohne irgendwelche Klimmz\u00fcge wie ich sie in meinem Beitrag \u00fcber den Optolink Splitter <\/a>beschrieben habe.<\/p>\n Keine Angst! Wahrscheinlichkeit, etwas kaputt zu machen ist ziemlich gering…<\/p>\n","protected":false},"excerpt":{"rendered":" oder Profi vs. Bastler Nach \u00fcber einem Jahrzehnt musste ich meine Webcam neu aufsetzen. Der USB Speicherstick, auf dem die \/root Partition lief, war verschlissen und unzuverl\u00e4ssig geworden. Immerhin – gut 12 Jahre hat er problemlos durchgehalten und dabei \u00fcber 200.000 Aufnahmen verarbeitet. Die alte Webcam lief auf Raspbian Jessie – inzwischen komplett veraltet und … Python – Das Externally Managed Environment Problem<\/span> weiterlesen Virtuelle Python Umgebung<\/h3>\n
Overengineered?<\/h3>\n
Erstmal andersrum probieren<\/h3>\n
Der Quick & Dirty Ansatz f\u00fcr risikofreudige Hobbyisten<\/h3>\n