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: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.
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:"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.
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: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.
mod_wsgi haelt sich genau an den WSGI Standard, im Gegensatz zu vielen andern Servern. Was heisst bitte "deutlich" unterscheiden?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.