Knopf bei virtuellen Umgebungen die systemweit gültig sein sollen

Probleme bei der Installation?
Antworten
dll-live
User
Beiträge: 43
Registriert: Dienstag 11. August 2020, 09:25
Wohnort: CH

Hallo Zusammen


Heute wollte ich meinen Raspberry Pi mit dem neues OS (Lite) aufsetzen und ihm anschliessend Zugriff auf die zentrale DB (NAS) erteilen.

Um mit Python auf die Datenbank zuzugreifen wollte ich

Code: Alles auswählen

pip install mysql-connector-python
verwenden.

Da kommt jedoch die "Fehler"-Meldung:

Code: Alles auswählen

error: externally-managed-environment

× This environment is externally managed
....
Der Sinn von virtuellen Umgebungen ist mir (so glaube ich jedenfalls) bekannt.

Jedoch frage ich mich wie ich Pakete installieren kann, welche SYSTEMWEIT gültig sein sollen (wie zum Beispiel: Den Mysql-connector)

Auf klärende Antworten freue ich mich.

Freundliche Grüsse
Daniel
Benutzeravatar
DeaD_EyE
User
Beiträge: 1293
Registriert: Sonntag 19. September 2010, 13:45
Wohnort: Hagen
Kontaktdaten:

Für Debian unstable habe ich das Paket gefunden: https://packages.debian.org/sid/python3-mysql.connector
Mittels pip Pakete systemweit zu installieren ist meistens eine schlechte Idee.

Ansonsten auf eigene Gefahr folgende Option beim Einrichten des venv nutzen: --break-system-packages.

Wenn das Paket für Debian vorhanden wäre, könntest du es einfach installieren und auch ohne zusätzliche Aktionen im venv nutzen.
sourceserver.info - sourceserver.info/wiki/ - ausgestorbener Support für HL2-Server
dll-live
User
Beiträge: 43
Registriert: Dienstag 11. August 2020, 09:25
Wohnort: CH

Hallo DeaD_Eye

Danke für deine Antwort.
Die Option: --break-system-packages habe ich gesehen - finde ich jedoch suboptional. GIBt es da keine besseren Varianten.
Unstable Pakete will ich nicht verwenden, die sind "gefährlich"....

Gruss Daniel
Benutzeravatar
sparrow
User
Beiträge: 4587
Registriert: Freitag 17. April 2009, 10:28

Naja, einen Tod musst du sterben.
Dein System warnt dich davor, Module systemweit zu installieren, weil das System selbst auf Python-Programme angewiesen ist, deren Umgebung du möglicherweise durch deine manuelle Installation von Paketen kaputt machst.
Also wenn du global installieren möchtest, musst du da durch.
Besser ist aber für jedes Projekt ein venv. Auch unter Windows (auch wenn es da die Warnung nicht gibt).
Zuletzt geändert von sparrow am Samstag 8. November 2025, 17:00, insgesamt 2-mal geändert.
Benutzeravatar
DeaD_EyE
User
Beiträge: 1293
Registriert: Sonntag 19. September 2010, 13:45
Wohnort: Hagen
Kontaktdaten:

Wieso installierst du nicht einfach mysql-connector-python im venv?
sourceserver.info - sourceserver.info/wiki/ - ausgestorbener Support für HL2-Server
Benutzeravatar
noisefloor
User
Beiträge: 4243
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,
dll-live hat geschrieben: Samstag 8. November 2025, 15:30 ... und ihm anschliessend Zugriff auf die zentrale DB (NAS) erteilen.
Wer ist denn "ihm" in dem Kontext? Für den Zugriff auf eine externe MySQL brauchst du ja erstmal kein Python, sondern "nur" ein MySQL Client Modul. Bzw. was ist denn Ziel des ganzen? Wer soll wie wo wann auf die externe Datenbank zugreifen? Und welche Rolle soll Python dabei spielen?

Und wenn du wirklich ein Python MySQL Modul für Trixie brauchst: pymysql und mysqldb sind in den stable Quellen.

Gruß, noisefloor
dll-live
User
Beiträge: 43
Registriert: Dienstag 11. August 2020, 09:25
Wohnort: CH

Hallo zusammen

Danke für die Antworten.

Machen wir nun "Butter bei die Fische" und legen alles offen...
Mein "alter" Pi hat sein EOL erreicht (OS Version Buster) nun gibt es ein grundlegenes Upgade.... - frisch aufgesetzt.

Ich habe diverse Scripte in Python (3.x) geschrieben. Die diverse Aufgaben erledigen (z.B: mit Flask einen WebServer um Lichter zu schalten oder mein Radio, ein SMS-Gateway das unterschiedliche Aufgaben erfüllt (Steuerung [VPN] und Statusmeldungen schickt))

Das "Herzstück" ist meine Datenbank, welche auf einem NAS läuft, da wird praktisch von jedem Script darauf zugegriffen (lesen, schreiben, update etc.)

Die Scripte laufen entweder zeitlich gesteuert mit Cronjob auslösung oder mittels systemd-unit Event gesteuert (die meisten mit einem (immer dem gleichen) Service-User.

Das SMS-Gateway funktioniert. SMS kann ich senden und empfangen die Weiterverarbeitung ist noch offen, sprich das Python-Script sollte mit der DB interagieren..


Gruss Daniel
Benutzeravatar
__blackjack__
User
Beiträge: 14223
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@dll-live: Das klärt noch nicht wirklich die Frage warum Du systemweit mysql-connector installieren musst. Falls es das nicht als Paket von der Linux-Distribution gibt, hat Noisefloor ja bereits zwei Alternativen genannt. Wenn man sich auf die DB API v2 beschränkt, sind die Pakete ja relativ leicht austauschbar. Im einfachsten Fall muss man nur die Importe austauschen und eventuell die `connect()`-Argumente anpassen. Ich persönlich bin deswegen ein Fan von SQLAlchemy, auch wenn man das ORM nicht nutzt, bügelt das eine ganze Menge an Unterschieden zwischen Modulen und Datenbanken glatt, so dass man leichter wechseln kann ohne den Code über die URI für die Verbindung hinaus ändern zu müssen.

Falls es mysql-connector sein muss, dann halt venvs. Entweder (sauberere Lösung) ein venv für jedes Programm, und dann halt in jedes venv mysql-connector installieren. Oder ein venv für alle Programme, dann braucht man es dort nur einmal rein installieren.
“Ich bin für die Todesstrafe. Wer schreckliche Dinge getan hat, muss eine angemessene Strafe bekommen. So lernt er seine Lektion für das nächste Mal.” — Britney Spears, Interview in der französischen Zeitung Libération, 2. April 2002
dll-live
User
Beiträge: 43
Registriert: Dienstag 11. August 2020, 09:25
Wohnort: CH

Hallo __blackjack__

Danke für deine Antwort.
Nun habe ich mehr Fragezeichen im Kopf als vorher....
Meine Überlegung ist wenn ich es Systemweit installiere brauche ich es nur einmal und alle Scripte ( und auch User) haben darauf Zugriff, sonst brauche ich (mind eine oder auch mehrere?) venv und muss immer darauf bedacht sein, dass diese auch mit eingebunden wird (bei jedem Script (und User))

Sehe ich das richtig oder habe ich einen Knopf?

Gruss Daniel
Benutzeravatar
noisefloor
User
Beiträge: 4243
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

dll-live hat geschrieben: Samstag 8. November 2025, 19:43 Meine Überlegung ist wenn ich es Systemweit installiere brauche ich es nur einmal und alle Scripte ( und auch User) haben darauf Zugriff, ...
Du sagst im vorherigen Post, dass alle systemd Unit unter dem gleichen User laufen - jetzt redest du von mehreren Usern... was denn jetzt?
sonst brauche ich (mind eine oder auch mehrere?) venv und muss immer darauf bedacht sein, dass diese auch mit eingebunden wird (bei jedem Script (und User))
Ob ein oder mehrere musst du selber wissen. Man kann alles in eine venv packen, normalerweise gilt es aber als "best practice", jedes Programm in eine eigenes venv zu packen.

Und was meinst du mit "einbinden"? Man kann venvs nicht einbinden. venvs sind - vereinfacht gesagt - "nur" eine Python-Umgebung, die vom systemweiten Python isoliert ist, was durch A) kopieren des systemweiten Python-Interpreters und B) Umbiegen von ein paar Umgebungsvariablen für das venv erreicht wird. Und ein venv muss nicht aktiv sein, um es zu nutzen. Du musst das Python-Skript nur mit dem vollen Pfad zum Python-Interpreter im venv aufrufen, dann "sieht" dieses Skript auch nur die Module, die im venv installiert sind. Spricht: geht auch ohne Probleme aus einer Service Unit heraus. Und in Units kann man den Benutzer angegeben, mit der die Unit laufen soll (falls sie nicht per default als root laufen soll).

Gruß, noisefloor
dll-live
User
Beiträge: 43
Registriert: Dienstag 11. August 2020, 09:25
Wohnort: CH

Hallo noisefloor

Die meisten Scripte laufen unter "meinem" User ein paar brauchen leider root rechte....
Im Umgang mit Systemvariablen, ist mir aufgefallen, dass diese von unterschiedlichen Stellen gelesen werden je nach dem wer sie startet (cronjob oder systemd) Ich weiss, das ist eine andere Baustelle, ich dachte ich könnte von da ableiten.... wahrscheinlich wieder zuviel zusammen gemixt....

zu der best practice -> das heisst dann ja wenn ich 10 scripte mit db zugriffe habe muss ich 10 venv erstellen und überall den mysql-conector nach installieren.

Zudem ist das bei einem update ja eine "grosse" Arbiet weil immer weider alle einzeln agepasst werden müssen....

Gruss Daniel
Benutzeravatar
sparrow
User
Beiträge: 4587
Registriert: Freitag 17. April 2009, 10:28

@dll-alive: Hier wurde doch schon gesagt, dass der Connector auch im Repository der Distribution enthalten ist. Warum installierst du den nicht?
dll-live
User
Beiträge: 43
Registriert: Dienstag 11. August 2020, 09:25
Wohnort: CH

Salü sparrow

Das stimmt, wahrscheinlich ist es das einfachste das zu machen und wenn ich dann weitere Python Pakete (z.B.Flask) brauche entsprechend zu suchen / wieder zu fragen.

Gruss Daniel
Benutzeravatar
noisefloor
User
Beiträge: 4243
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

dll-live hat geschrieben: Samstag 8. November 2025, 20:20 Im Umgang mit Systemvariablen, ist mir aufgefallen, dass diese von unterschiedlichen Stellen gelesen werden je nach dem wer sie startet (cronjob oder systemd)
Dann nimm' statt cron systemd Timer Units, dann bis du komplett im systemd Universum.
zu der best practice -> das heisst dann ja wenn ich 10 scripte mit db zugriffe habe muss ich 10 venv erstellen und überall den mysql-conector nach installieren.
Ja - aber das ist die falsche Denke. Du erstellst ein venv ja, um eine Python Umgebung vom systemweiten Python und anderen venvs zu installieren. Ob 10 Skripte 10 venv brauchen, musst du entscheiden. Du kannst rein technisch auch alles in ein venv packen.
Zudem ist das bei einem update ja eine "grosse" Arbiet weil immer weider alle einzeln agepasst werden müssen....
.
Was jetzt "anpassen"? Wenn du ein Distributionsupgrade machst, dann musst du das venv nicht unbedingt anpassen. Es sei denn, du willst auf eine neuere Python-Version gehen, dann musst du das venv sowieso neu anlegen.

Gruß, noisefloor
dll-live
User
Beiträge: 43
Registriert: Dienstag 11. August 2020, 09:25
Wohnort: CH

Hallo noisefloor

Alles mit systemd zu machen wäre natürlich eine Möglichkeit (evtl eine doofe Frage, gibt es eine Übersicht (von meinen systemd-Unit) wo ich sehe welche angelegt sind und zu welchen Zeiten die laufen (analog zu crontab -e)? Dies ist aber ein Nebenschauplatz....

Bezüglich der anzahl venv, gemäss sturer Anwendung von best practice => 1 Script 1 venv folglich dann auch 10 Scripte 10 venv. Ob dies auch sinnvoll ist wenn alle 10 Scripte die gleichen Module brauchen einfach unterschiedliche Aufgaben erledigen und nicht in einem Script zusammen gefasst sind steht auf einem anderen Blatt....

Zum Punkt "anpassen" - da war ich in gedanken schon weiter, wenn es dann mal soweit sein sollte.... es neue (Unter-)Versionen (gleiche Hauptnummer) von den Modulen gibt und ich diese updaten möchte..

Gruss Daniel
Benutzeravatar
__blackjack__
User
Beiträge: 14223
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@dll-live: Ich würde nicht sagen ein venv pro Skript sondern ein venv pro Projekt. Wenn das Projekt aus mehreren „entry points“ besteht, macht es natürlich keinen Sinn die auf verschiedene venvs zu verteilen.

Was man vielleicht auch überlegen könnte, ist das ordentlich installierbar zu machen. Also auch das eigene Programm als Package mit „entry points“. Dann kann man das auch in das venv installieren und einfach symbolische links von den eigenen Programmen im bin/-Vezeichnis vom venv in /usr/local/bin anlegen.

Wenn man 10 venvs hat, dann muss man die natürlich alle einzeln anfassen wenn man mal Abhängigkeiten aktualisieren will. Man kann das aber auch anders herum betrachten: Wenn man eine Abhängigkeit aktualisiert die Anpassungen am eigenen Code erfordert, dann kann man das in 10 kleinen Schritten machen, und muss nicht alle 10 Skripte auf einmal anpassen bis alles wieder läuft. Das hat alles so seine Vor- und Nachteile.
“Ich bin für die Todesstrafe. Wer schreckliche Dinge getan hat, muss eine angemessene Strafe bekommen. So lernt er seine Lektion für das nächste Mal.” — Britney Spears, Interview in der französischen Zeitung Libération, 2. April 2002
Benutzeravatar
noisefloor
User
Beiträge: 4243
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

@dll-live: Übersicht, was systemd so kann und was man damit machen kann https://wiki.ubuntuusers.de/systemd/. Das allermeiste, was da steht, funktioniert 1:1 unter Debian bzw. Raspberry Pi OS genau so.
...es neue (Unter-)Versionen (gleiche Hauptnummer) von den Modulen gibt und ich diese updaten möchte..
Ein weiterer Vorteil von venvs ist ja eben auch, dass du pro venv selber festlegen kannst, welchen Release eines Moduls du installieren willst und ob du diesen Updates (oder eben nicht.
Gruß, noisefloor
dll-live
User
Beiträge: 43
Registriert: Dienstag 11. August 2020, 09:25
Wohnort: CH

Hallo zusammen

Danke für eure Ausführungen und die Geduld mit mir. Für mich ist das Thema "erledigt".
Werde das System wohl mit verschiedenen venv aufsetzen und schauen was ich wie zusammenfasse (zusammengehörende Scripte)....
Als DB Connector werkelt nun mysqldb (sudo apt install python3-mysqldb) aus den stable Quellen .
Bezüglich den systemd-Unit werde ich mich weiter vertiefen. bis jetzt habe ich leider noch keine Möglichkeit gefunden, auf einfache Weise tabellenartig die (von mir) angelegten systemunits und deren Ausführung (event basiert oder Zeitgesteuert (und wann)) anzuzeigen.

z.B:
Bezeichnung Ausführung
Job1 Eventpasiert
Job2 Zeitgesteuert (täglich 6:30)
Job3 Zeitgesteuert (um 10 und 12 Uhr jeweils Montag und Dienstag....)
etc.

Gruss Daniel
Antworten