2014-12-01 8 views
7

Dies ist ein Problem, das ich auf allen meinen Seiten, auf denen Django 1.7 in mod_wsgi läuft, festgestellt habe. Der Kernpunkt des Problems ist, dass, wenn ich bei der lokalen Entwicklung einen schwerwiegenden Fehler in die Codebasis einfüge und ihn anschließend korrigiere, das Codeüberwachungsskript die Korrektur nicht erkennt.Fehler bei der Code-Änderung bei Django 1.7 auf mod-wsgi

Ich verwende Graham Dumpleton's monitor.py script, um Änderungen an der Codebasis zu erkennen, wenn ich lokal entwickle (ich benutze Apache und nicht den Django-Entwicklungsserver).

Es ist immer in Django verwendet < = 1,6, zu arbeiten, aber in Django 1.7 bekomme ich folgende Fehlermeldung:

File "/home/me/.virtualenvs/myvirtualenv/lib/python2.7/site-packages/django/core/wsgi.py", line 14, in get_wsgi_application 
    django.setup() 
File "/home/me/virtualenvs/myvirtualenv/lib/python2.7/site-packages/django/__init__.py", line 21, in setup 
    apps.populate(settings.INSTALLED_APPS) 
File "/home/me/.virtualenvs/myvirtualenv/lib/python2.7/site-packages/django/apps/registry.py", line 78, in populate 
    raise RuntimeError("populate() isn't reentrant") 
RuntimeError: populate() isn't reentrant 

Das Ärgerliche ist, dass, wenn ich den Fehler zu korrigieren, monitor.py nicht erkennt Die Änderung, also muss ich entweder Apache neu starten, oder eine andere Datei berühren, die bereits geladen wurde (zB die Einstellungsdatei).

Ich denke, das liegt daran, dass "der Neuladecode nur importierte Dateien (aka sys.modules) überwacht" (source). Da die falsche Datei nicht erfolgreich importiert wurde, weiß monitor.py nicht, den Prozess neu zu starten.

+0

Dies ist ähnlich, wie der Python Interactive Interpreter nicht neu laden kann. Es gibt sowieso eine Kopie des Codes im Speicher und in vielen Fällen funktioniert das Löschen der '.pyc/.pyo'-Dateien nicht. Wir haben diesen Fehler behoben, indem wir einen Watcher auf alle Dateien gesetzt haben und den Apache-Einstiegspunkt ('wsgi') bei Änderung neu geladen haben. Dies hat eine leichte Verzögerung, und Sie können es für die Produktion ausschalten. – kunl

+0

etwas ähnliches passierte mir mit uwsgi. Ich begann dann mit need-app = true. Dies macht uwsgi die App zu verwerfen, weil es nicht korrekt geladen wird. Sobald Sie die neue Änderung entwickelt haben, wird es funktionieren. Vielleicht kannst du etwas Ähnliches finden. –

+1

Ich bin am Ende auf den Django-Entwicklungsserver für die lokale Entwicklung gewechselt. Wenn Sie keinen wirklich guten Grund haben, würde ich sagen, dass es ein viel besserer Ansatz ist, als mit Apache und mod_wsgi für die lokale Django-Entwicklung zu arbeiten. – seddonym

Antwort

0

Ich bin mir nicht sicher, was Ihr Deployment-Prozess ist oder Ihr Produktionsbetriebssystem, aber in der Linux/Ubuntu-Welt gibt es einen OS-Befehl namens pyclean. Während meiner Django/Python-Deployment-Skripte (normalerweise über Fabric) gebe ich den Befehl "pyclean" aus. im Projektstamm. Dieses Skript löscht rekursiv alle .pyc-Dateien, die im aktuellen Ordner beginnen. Ich hoffe das hilft.