Hallo Leute,
ich benutze Python 3.5 (Miniconda) und PyCharm auf nem Mac und würde gerne ein / mehrere Python Programm(e) als Daemon(s) laufen lassen, welche autark entsprechend ihrer Programmierung mit einer Datenbank interagieren. Zusätzlich möchte ich ein Webinterface erstellen, mit welchem ich diesen Daemon später starten und stoppen und Settings einstellen kann, die beim Start ausgelesen werden usw. Ich arbeite mit Django und HTML, JS sowie CSS3 Kenntnisse sind vorhanden. Soviel kurz zum Big-Picture.
Wie baut man so generell einen Daemon/Service mit dem man interagieren kann mit Python?
Was mir da nur so einfällt, wäre halt ne riesige endlos while - Schleife, die permanet eine Textdatei auf neue settings / input scannt und dann entsprechend reagiert, aber ich hab irgendwie das Gefühl, dass das viel eleganter geht. Könnt ihr mir ein paar Hinweise geben, wie hier so die best practice ist? Gerne auch Verweise auf Tutorials oder weiteren Lesestoff oder ein paar gute Suchbegriffe, die mich weiterbringen.
Eine weitere Frage genereller Natur:
Mir ist klar wie man virtuelle Umgebungen erstellt und auch wie man mehrere unterschiedliche Python Versionen benutzen kann etc.
Jedes Tutorial dazu beschränkt sich aber immer nur darauf, wie man im Terminal zwischen unterschiedlichen Umgebungen switchen kann etc. Alles Gut, funzt auch. Was mich aber interessiert, ist, wie ich zur selben Zeit bspw. ein Py27 und ein Py35 Programm aus unterschiedlichen Umgebungen als Service im Hintergrund und ohne geöffnetes Terminal laufen lassen kann, ohne, dass sich die einzelnen Envs gegenseitig in die Quere kommen. Das Aktivieren / Deaktivieren von Envs ist ja im Grunde nix anderes als temporär den aktiven Python Pfad in der Umgebungsvariable zu ändern. Also kann ja immer nur eine Umgebung aktiv sein. Ist das also überhaupt möglich gleichzeitig?
Besten Dank für eure Tipps.
brave
Deamons / Virtuelle Umgebungen
Um's dir etwas zu erleichtern, könntest du auf eine Bibliothek zurückgreifen:
https://pypi.python.org/pypi/python-daemon/2.1.1
(s. a. https://www.python.org/dev/peps/pep-3143/)
Zur Interprozesskommunikation gibt es unter unixoiden System verschiedene Ansätze; gängig wären m.W.n. nach etwa Sockets.
https://pypi.python.org/pypi/python-daemon/2.1.1
(s. a. https://www.python.org/dev/peps/pep-3143/)
Zur Interprozesskommunikation gibt es unter unixoiden System verschiedene Ansätze; gängig wären m.W.n. nach etwa Sockets.
Ja, indem du die virtuellen Umgebungen als separate Prozesse startest, beispielsweise in einem einfachen Shellskript.brave hat geschrieben: Also kann ja immer nur eine Umgebung aktiv sein. Ist das also überhaupt möglich gleichzeitig?
Tatsächlich macht man es genauso wie du dir es vorstellst. Allerdings kommuniziert man mit dem Prozess üblicherweise direkt z.B. über ein Signal oder durch neustarten dass die Konfiguration neugeladen werden soll anstatt dass der Service dies von sich aus automatisch tut.
Ansonsten ist natürlich relevant wie man so einen Service startet, dies tut man unter OS X/macOS mit launchd und unter Linux mit systemd. Wenn man damit arbeitet kann und sollte man auf eine Bibliothek wie python-daemon übrigens verzichten.
Ansonsten ist natürlich relevant wie man so einen Service startet, dies tut man unter OS X/macOS mit launchd und unter Linux mit systemd. Wenn man damit arbeitet kann und sollte man auf eine Bibliothek wie python-daemon übrigens verzichten.
Virtualenv pythons muessen nicht aktiviert werden - das ist nur Bequemlichkeit fuer die Kommandozeile.
Du kannst genausogut den vollen Pfad zu <virtualenvroot>/bin/python als Interpreter benutzen - und dann wird dieser Interpreter alles aus dem venv benutzen. Kein Grund also fuer irgendwelche ShellShenanigans(tm)
Du kannst genausogut den vollen Pfad zu <virtualenvroot>/bin/python als Interpreter benutzen - und dann wird dieser Interpreter alles aus dem venv benutzen. Kein Grund also fuer irgendwelche ShellShenanigans(tm)
Danke Leute.
@__deets__
Das geht ja, aber ist dann auch sichergestellt, dass das Script, welches einen absoluten Pfad in der Shebang hat auch mit den in der Env installierten Paketen arbeitet anstatt denen, der systemweiten Python installation?
@__deets__
Das geht ja, aber ist dann auch sichergestellt, dass das Script, welches einen absoluten Pfad in der Shebang hat auch mit den in der Env installierten Paketen arbeitet anstatt denen, der systemweiten Python installation?
@brave: zum einen Ja, zum anderen sollte es erst gar keinen festen Pfad in der Shebang-Zeile haben.
Code: Alles auswählen
#!/usr/bin/env python
Grundsätzlich für eine Session --> ja.
Das will ich ja aber eben gerade NICHT. Weil dann immer die Standard-Python Installation und deren Pakete des gerade angemeldeten Benutzers hernagezogen werden, wenn das Skript startet.
Was ich erreichen will ist Folgendes:
Ich habe bspw. 3 Python Programme, die von unterschiedlichen Entwicklern mit unterschiedlichen Pythonversionen und Paketversionen programmiert wurden. Diese sollen alle zur selben Zeit in ihren eigenen virtuellen Umgebungen mit entsprechend benötigten Paketversionen und Pythonversionen laufen ohne sich gegenseitig ins Gehege zu kommen.
Das kann ich ja nicht indem ich jedes Programm mit der Shebang #!/usr/bin/env python starte, weil es nur eine Python Version pro Env gibt. Welche Env sich das Script dann? Wahrscheinlich die die gerade aktiviert ist und ggf. nicht zum Skript/Programm passt. Also suche ich eine Möglichkeit die Python Envs voneinander zu entkoppeln. Das ist mir immer noch nicht klar, wie das gehen soll, außer dass ich einen absoluten Pfad in der Shebang angebe, der auf die spezielle gewünschte Venv zeigt.
Das will ich ja aber eben gerade NICHT. Weil dann immer die Standard-Python Installation und deren Pakete des gerade angemeldeten Benutzers hernagezogen werden, wenn das Skript startet.
Was ich erreichen will ist Folgendes:
Ich habe bspw. 3 Python Programme, die von unterschiedlichen Entwicklern mit unterschiedlichen Pythonversionen und Paketversionen programmiert wurden. Diese sollen alle zur selben Zeit in ihren eigenen virtuellen Umgebungen mit entsprechend benötigten Paketversionen und Pythonversionen laufen ohne sich gegenseitig ins Gehege zu kommen.
Das kann ich ja nicht indem ich jedes Programm mit der Shebang #!/usr/bin/env python starte, weil es nur eine Python Version pro Env gibt. Welche Env sich das Script dann? Wahrscheinlich die die gerade aktiviert ist und ggf. nicht zum Skript/Programm passt. Also suche ich eine Möglichkeit die Python Envs voneinander zu entkoppeln. Das ist mir immer noch nicht klar, wie das gehen soll, außer dass ich einen absoluten Pfad in der Shebang angebe, der auf die spezielle gewünschte Venv zeigt.
Mein Vorschlag wäre, an den Shebang-Zeilen der Skripte selbst nichts zu verändern, sondern dafür zu sorgen, dass vorab zumindest die PATH-Variable richtig umgebogen wird:
Das tut das activate Skript, abgesehen von den Komfortfunktionen. Wenn man, wie von __deets__ vorgeschlagen, darauf verzichten möchte, muss man sich vor dem Aufruf des Pythonskripts selbst darum kümmern (und in beiden Varianten hinterher wieder aufräumen).
Code: Alles auswählen
$ env python -c "import sys; print(sys.executable); print(sys.path)"
/usr/bin/python
['', '/usr/lib/python35 … ]
$ PATH="test_env/bin/:$PATH" env python -c "import sys; print(sys.executable); print(sys.path)"
/home/benutzer_name/test_env/bin/python
['', '/home/benutzer_name/test_env/lib/python35…]
@brave Ja, genau das ist dann sichergestellt.
Du kannst dein shebang natuerlich umstellen, ich wuerde stattdessen einfach an der aufrufenden Stelle den vollen Pythoninterpreterpfad angeben: /home/user/virtualenvs/meinvenv/bin/python. Das ist besser als an irgendwelchen Pfaden zu schrauben, die dann wieder zurueckgedreht wreden muessen - vielleicht.
Das ist gegenueber dem Shebang vorzuziehen, weil dein Skript sonst ueber seine Umgebung mehr wissen muss als notwendig. Wenn der gleiche Code in einem anderen VENV laufen soll, ist dann naemlich essig.
Du kannst dein shebang natuerlich umstellen, ich wuerde stattdessen einfach an der aufrufenden Stelle den vollen Pythoninterpreterpfad angeben: /home/user/virtualenvs/meinvenv/bin/python. Das ist besser als an irgendwelchen Pfaden zu schrauben, die dann wieder zurueckgedreht wreden muessen - vielleicht.
Das ist gegenueber dem Shebang vorzuziehen, weil dein Skript sonst ueber seine Umgebung mehr wissen muss als notwendig. Wenn der gleiche Code in einem anderen VENV laufen soll, ist dann naemlich essig.