Das deutsche Python-Forum

Defnull hat geschrieben:Mit "magisch" meine ich den __name__ Trick, nicht die Benutzung von __file__. Wenn ich es richtig verstanden habe, benutzt Flask den Inhalt von __name__ um anschließend im sys.modules dict nach dem Modul und seinem __file__ Attribut zu schauen. Flask gelangt so mit ein paar Umwegen an den Pfad zum Modul, in dem Flask instantiiert wird.

Das ist kein Umweg. Der Unterschied ist, dass Modul code im __dict__ ausgefuehrt wird, das spaeter nach sys.modules kommt und man halt mit sys.modules[__name__] an ein Modul rankommt. So findet auch Pickle seine Sachen. Keine Magie, alles dokumentiertes Verhalten.

Defnull hat geschrieben:"Unmagischer" fände ich dagegen eine "app.set_root(__file__)" oder "app=Bottle(root=__file__)" Lösung. Dann weiß der Benutzer, was er tut und kann dieses Wissen auch ausnutzen, um Sonderfälle (z.B. komplett extern gespeicherte Ressourcen) zu lösen.

Und was waere der Sinn der Sache? In Flask ist Dokumentiert: die Templates sind im Ordner "templates", die statischen Dateien im Ordner "static" direkt neben dem Script/im Package. Wenn man wo anders Templates haben will, muss man sich halt Flask subclassen und die template Method "create_jinja_env" ueberschreiben.

Defnull hat geschrieben:Eigentlich tritt das Problem nur mit mod_wsgi auf, da der Benutzer dort keine Kontrolle über das Arbeitsverzeichnis hat und es auch nicht ändern darf.

WSGI sagt nicht, dass du ein stabiles working directory haben kannst. Es gibt mehr als genug Server wo das CWD sich von selber aendert. Naemlich alle, die nicht forken und mehrere Apps haben. Da man auch mit Paste und co. mehrere Apps in einen Server werfen kann gilt das fuer so ziemlich alle Server.

Defnull hat geschrieben:Da mod_wsgi auch in anderen Punkten deutlich vom üblichen Deployment abweicht, hab ich dafür gerade einen neuen Server Adapter geschrieben.

mod_wsgi haelt sich genau an den WSGI Standard, im Gegensatz zu vielen andern Servern. Was heisst bitte "deutlich" unterscheiden?

Äh sorry, ich hab wohl geschrieben, ohne zu denken. Natürlich verwende ich mod_wsgi, die ganzen Hinweise hier im Forum, mod_python nicht mehr zu verwenden kann man ja gar nicht übersehen und ich habe es auch wirklich genau wie im Tutorial gemacht.

Wenn es ein Apache-Konfigurationsfehler ist, was genau ist dann nicht richtig konfiguriert?

Jack Daniels: So wie die im Tutorial. Bei mir (gerade getestet mit einer frischen ubuntu Installation) funktioniert die hervorragend. Wenn deine nicht funktioniert, zeig sie uns doch mal.

mitsuhiko: Wir reden aneinander vorbei.

Zum Thema "__main__" kann ich nur sagen: Geschmackssache. Ich finde den Weg von "__main__" über "sys.modules" nach "module.__file__" umständlicher und undurchsichtiger für den User, als ihn gleich nach "__file__" zu fragen. Ich finde die Aussage "app.set_root(__file__) wird heran gezogen, um relative Pfade von Templates und statischen Dateien aufzulösen." einfacher und verständlicher und vor allem expliziter, als "Flask benutzt import_name irgendwie, um relative Pfade auf zu lösen. Erweiterungen interpretieren das auch manchmal. Bei Packeten solltest du es allerdings von Hand angeben." (Wortlaut der Flask API Dokumentation). Dazu kommt, das bei Bottle das Erstellen eines App-Objektes optional ist. Eine Methode, die man nachträglich aufrufen kann (aber nicht muss) ist daher eh besser geeignet als ein erzwungener Instantiierung-Parameter, den man bei einfachen Stand-Alone Applikationen gar nicht braucht.

mitsuhiko hat geschrieben:

Defnull hat geschrieben:Da mod_wsgi auch in anderen Punkten deutlich vom üblichen Deployment abweicht, hab ich dafür gerade einen neuen Server Adapter geschrieben.

mod_wsgi haelt sich genau an den WSGI Standard, im Gegensatz zu vielen andern Servern. Was heisst bitte "deutlich" unterscheiden?

Ich führe hier keine Grundsatzdiskussionen, sondern beziehe mich auf Bottle (schau mal auf den Thread-Titel). Mit Deployment meine ich natürlich das übliche Deloyment mit Bottle und damit die Benutzung von Server Adaptern. Da weicht mod_wsgi nun mal deutlich ab, da es bisher nicht mit run() angebunden werden konnte. Von "mod_wsgi hält sich nicht an WSGI" steht in meinem Satz nichts.

Was lange währt, wird endlich gut. Bottle 0.8.1 ist da

Release Notes: http://bottle.paws.de/docs/0.8/changelog.html
Download: http://pypi.python.org/pypi/bottle/0.8.1

Hallo,

Frage zur API Bottle 0.8.1 - auch wenn es vllt. implizit aus dem Changelog herovrgeht...

Alles andere aus der Bottle 0.6.x API läuft auch nach wie vor auf Bottle 0.8.1?

Gruß, noisefloor

noisefloor hat geschrieben:Hallo,
Alles andere aus der Bottle 0.6.x API läuft auch nach wie vor auf Bottle 0.8.1?

Wenn ich nichts vergessen hab, dann ja. In 0.8.2 kommt auch noch ein wenig background compatibility code dazu.

Bottle 0.9-dev hat eine neue Hook-API spendiert bekommen. Das macht es deutlich einfacher, plugins zu schreiben. Siehe: http://bottle.paws.de/docs/dev/plugindev.html

Ich weiß: Dies ist mindestens eine 50/50 Frage.
Halb Python - Halb Linux.
Ich stelle sie trotzdem hier, weil ich denke das es spezifischer ist.

Wie starte ich meine Bottle-Anwendung automatisch bei Systemboot von Ubuntu 10.4 Server.
Ich benutze die run()-Variante ohne apache o.ä.

Ich habe mir viel Info über die verschiedenen Möglichkeiten unter Linux zu Gemüte geführt, bin aber nicht zu einer Best- oder Einfachst- oder Sinnvollstlösung gekommen.


Gibt es dazu bereits eine 'bottlespezifische' Erläuterung die ich nicht entdeckt habe?
Gibt es eine für Bottle bessere Möglichkeit eines "Autostart"?

Danke.


MrNiceTry

Hallo,

grundsätzlich ist Bottle ja nichts anders, als "irgendein" Python-Programm. Sprich, du musst es auch starten wir ein Python-Programm. Und da bietet sich Autostart nun mal an.

Warum kannst oder möchtest du denn nicht Apache (oder einen anderen Webserver) nehmen?

Gruß, noisefloor

Fuer die Linux-Seite:
Einfachst: Starten in `/etc/rc.local` (einfach eine Zeile mit dem noetigen Befehl hinzufuegen)
Best/Sinnvollst: Initskript schreiben

Hab die Variante rc.local getestet.

Folgendes Problem tritt auf:

Normaler Systemboot:
Danach von Hand gestartet funktioniert es: Was ist los damit ?
Hab ich was falsch gemacht ?

MrNiceTry

Mmmh, denn *vollen* Traceback bitte? :)

Hallo Dauerbaustelle.


Das ist bereits der "volle" Traceback.

Aus dem Terminal der seriellen Serverkonsole (von Strato) rauskopiert.

Mehr gibt es da nicht.

Da fehlt aber noch was, ein voller Python-Traceback sieht anders aus (Name des Fehler z.B.).

Nein, leider gibt es da nicht mehr.

Meine Anwendung / Bottle wird aus rc.local beim Booten gestartet.

Bei Stratoservern kann man sich über eine Remotekonsole bereits den Bootprocess verfolgen.

Das ist leider die einzige Meldung.

Und wenn ich danach das gleiche Script manuell starte, läuft es fehlerfrei.

make_server() ist eine Funktion von wsgiref.simple_server und scheitert wahrscheinlich dabei, an den entsprechenden netzwerk-port zu binden. Das ist natürlich grob geraten, da die Fehlermeldung mitten drin abbricht. Munter weiter spekuliert würde ich mal darauf tippen, das der Server seine IP per DCHP bezieht und zum Zeitpunkt des Skriptes noch nicht bezogen hat. Daher scheitert das Binden an '81.xxx.xxx.xxx'. '0.0.0.0' könnte dagegen funktionieren. Einen Versuch wäre es wert.

rc.local ist unter Ubuntu übrigens als veraltet (deprecated) markiert. Soweit ich weiß, ist upstart ( http://upstart.ubuntu.com/getting-started.html ) der neue Standard, init-scripte funktionieren aber weiterhin.

Hallo Defnull.

Danke für Deine spontane Unterstützung.

Habe die 0.0.0.0 Variante getestet.
Startet und läuft. Aber zu gut...
Bottle zeigt seine übliche Startmeldung in der Remoteconsole.
Diese ist aber ab sofort eingefroren. Die normalerweise angezeigte Login-Aufforderung kommt nicht mehr.
Bottle lässt sich mit ctrl-C NICHT abbrechen.

rc.local war ein Vorschlag hier aus dem Forum.

Ich schaue mir upstart jetzt mal genauer an und berichte dann.


Danke.

MrNiceTry

Hallo,

Upstart ist dazu da, die ganzen Dienst beim Systemstart hochzufahren (z.B. NetworkManager, MySQL, Apache etc. - was halt so installiert ist). Wenn du Bottle bzw. den Bottle-Server nicht als Dienst starten willst, dann brauchst du kein Upstart.

Leider sind die Server von ubuntuuser.de gerade down aber lies' doch mal den Artikel zu Autostart - das könnte was für dich sein.

Gruß, noisefloor

Hallo noisefloor.


Dienst oder nicht Dienst, das ist hier die Frage?

Was macht denn mehr Sinn? Bottle als Dienst oder Anwendung?

Ich bin nicht in der Lage das zu beurteilen.

Am Schluß ist Bottle doch ein Webserver.
Und Webserver sind doch eigentlich mehr ein Dienst. Oder ?

Hallo,

Am Schluß ist Bottle doch ein Webserver.

Nee, isses nicht. Bottle ist ein Web Framework, dass halt auch mittels Bottle "erzeuge Seiten" (bzw. genau genommen Responses) über diverse Webserver, wie z.B. den Python WSGI Referenzserver, liefern kann.

Wenn du den Applikation als Dienst laufen lassen willst - was ja durchaus sinnvoll sein kann - warum bindest du Sie dann nicht direkt an einen "richtigen" Webserver wie z.B. Apache. Die nötigen Rechte hast du auf dem Rechner ja scheinbar, sonst hättest du keinen Zugriff auf die Upstart Jobs. Das ist a) performanter und b) wesentlich einfacher.

Gruß, noisefloor