2014-12-01 12 views
7

Questo è un problema che ho riscontrato su tutti i miei siti che eseguono Django 1.7 in mod_wsgi. Il nocciolo del problema è che se, mentre si sviluppa localmente, introduco un errore fatale nella base di codice, e successivamente lo correggo, lo script di monitoraggio del codice non rileva la correzione.Monitoraggio del cambio di codice malfunzionamento con Django 1.7 su mod-wsgi

Io uso Graham Dumpleton's monitor.py script per rilevare le modifiche al codebase quando sto sviluppando localmente (io uso apache piuttosto che il server di sviluppo Django).

E 'sempre usato per lavorare in Django < = 1.6, ma in Django 1.7 ottengo il seguente errore:

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 

La cosa irritante è che se correggere l'errore, monitor.py non rileva il cambiamento, quindi devo riavviare apache, o toccare un altro file che è già stato caricato (ad esempio il file delle impostazioni).

Penso che questo sia dovuto al fatto che "il codice di ricarica monitora solo i file importati (aka sys.modules)" (source). Quindi, poiché il file errato non è stato importato correttamente, monitor.py non sa di riavviare il processo.

+0

Questo è simile al modo in cui l'interprete interattivo python non può vivere ricaricare perfettamente. C'è comunque una copia del codice nella memoria e in molti casi l'eliminazione dei file '.pyc/.pyo' non funziona. Abbiamo corretto questo errore mettendo un watcher su tutti i file e ricaricando il punto di ingresso di apache ('wsgi') in caso di modifica. Questo ha un leggero ritardo e puoi spegnerlo per la produzione. – kunl

+0

mi è successo qualcosa di simile usando uwsgi. Ho quindi iniziato a utilizzare need-app = true. Questo fa sì che uwsgi scarichi l'app perché non sta caricando correttamente. Quindi, una volta sviluppato il nuovo cambiamento, funzionerà. Forse puoi trovare qualcosa di simile. –

+1

Ho finito per passare al server di sviluppo Django per lo sviluppo locale. A meno che tu non abbia una buona ragione, direi che è un approccio molto migliore rispetto a lavorare con Apache e mod_wsgi per lo sviluppo locale di Django. – seddonym

risposta

0

Non sono sicuro di quale sia il processo di distribuzione o del sistema operativo di produzione, ma nel mondo Linux/Ubuntu esiste un comando del sistema operativo chiamato pyclean. Durante i miei script di distribuzione di Django/Python (di solito tramite fabric) emetto il comando "pyclean". nella radice del progetto. Questo script elimina in modo ricorsivo tutti i file .pyc che iniziano nella cartella corrente. Spero che aiuti.

Problemi correlati