Das deutsche Python-Forum

Gibt es eigentlich eine Sichere Method festzustellen, ob die django-app gerade mit dem Development Server läuft oder mit einem echten?

Das einzige was mir einfällt: Nachsehen, was sich in os.environ tummelt...

Hi,

Du könntest vielleicht request.META['SERVER_SOFTWARE'] prüfen. Der Development-Server sagt dort u'WSGIServer/0.1 Python/2.5.1'. Ein anderer Server möglicherweise (kann ich jetzt nicht prüfen) etwas anderes. Ein anderes Indiz wäre, wenn dein System auf localhost:8000 läuft. Was genau willst du erreichen?

Stefan

sma hat geschrieben:Ein anderes Indiz wäre, wenn dein System auf localhost:8000 läuft. Was genau willst du erreichen?

Mehr als ein Inziz ist das jedoch nicht, denn manchmal lässt man den WSGI-Server auch auf 0.0.0.0 lauschen oder hat im Produktiveinsatz den HTTPd auf Port 8000 und setzt einen Squid-Proxy davor.

Die Idee war, die urls.py dynamisch anzupassen. Es geht um das Ausliefern von statischen Dateien mittels 'django.views.static.serve'...

Momentan muss man die url.py halt selbst anpassen, siehe:
http://pylucid.net:8080/pylucid/browser ... rls.py#L97

Hm, ich ja ein Fan von automatischen Konfigurationen, wo man gerade nicht daran denken muss, Dateien manuell zu ändern. Ich muss außerdem zugeben, dass ich deinen Code recht unübersichtlich aufgrund deinen "comment spams" finde. Bin kein Fan von Trennlinien.

Im Fall von static-Dateien habe ich in meiner urls.py-Datei einfach diese ganz hinten stehen und erwarte, dass im Produktivbetrieb unser Lighttpd dafür sorgt, dass so eine URL niemals bei Django ankommt. Ich sah keine Notwendigkeit, dies zu einer bedingten Anweisung zu machen.

Die Sache mit den URL-Präfixes hatten wir auch, ich hatte mich für eine Lösung mit eigenen Funktionen entschieden, z.B. so

jens hat geschrieben:Gibt es eigentlich eine Sichere Method festzustellen, ob die django-app gerade mit dem Development Server läuft oder mit einem echten?

Die Lösung ist eigentlich recht einfach:

siehe: https://github.com/jedie/PyLucid/commit ... 4a0eb76a3e

(Mensch... Seit 2007 vergessen...)

Wieso `startswith`?

Hm. Gute Frage

Eigentlich sollte das auch funktionieren: Damit muß man auch nicht testen ob sys.argv >= 2 ist...


...oder?

jop

Wozu überhaupt if? Geht noch einfacher, in die settings.py kommt das rein: