Come posso sapere se la mia applicazione Django è in esecuzione sul server di sviluppo o meno?
https://stackoverflow.com/questions/1291755
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Come posso essere certo che la mia applicazione sia in esecuzione sul server di sviluppo o meno?Suppongo che potrei controllare il valore di settings.DEBUG e supporre se DEBUG È True quindi è in esecuzione sul server di sviluppo, ma preferirei saperlo con certezza piuttosto che affidarmi alla convenzione.
Soluzione
server = request.META.get('wsgi.file_wrapper', None)
if server is not None and server.__module__ == 'django.core.servers.basehttp':
print('inside dev')
Naturalmente, wsgi.file_wrapper potrebbe essere impostato su META, e hanno una classe da un modulo chiamato django.core.servers.basehttp da estrema coincidenza su un altro ambiente di server, ma spero che questo avrà coperto.
A proposito, ho scoperto questo facendo un modello sintatticamente non valida durante l'esecuzione sul server di sviluppo, e cercato roba interessante sul Traceback e le sezioni Request information, quindi sto solo modificando la mia risposta a corroborare con le idee di Nate.
Altri suggerimenti
ho messo il seguente nel mio settings.py di distinguere tra il server dev standard di produzione:
import sys
RUNNING_DEVSERVER = (len(sys.argv) > 1 and sys.argv[1] == 'runserver')
Questa si basa anche su convenzione, tuttavia.
(Amended per il commento di Daniel Magnusson)
In genere ho impostato un environment variabile chiamata e impostarlo su "sviluppo", "messa in scena" o la "produzione". All'interno del file delle impostazioni posso quindi aggiungere logica di base per modificare le impostazioni che vengono utilizzati, in base all'ambiente.
Modifica Inoltre, si può semplicemente utilizzare questa logica per includere diversi file settings.py che sostituiscono le impostazioni di base. Ad esempio:
if environment == "DEBUG":
from debugsettings import *
Di solito questo funziona:
import sys
if 'runserver' in sys.argv:
# you use runserver
Basandosi sulla settings.DEBUG è più eleganti AFAICS modo in cui è utilizzato anche in Django base di codice in occasione.
Suppongo che ciò che si vuole veramente è un modo per impostare quella bandiera automaticamente senza bisogno di aggiornare manualmente ogni volta che si carica il progetto al server di produzione.
Per questo ho verificare il percorso di settings.py (in settings.py) per determinare quale server il progetto è in esecuzione su:
if __file__ == "path to settings.py in my development machine":
DEBUG = True
elif __file__ in [paths of production servers]:
DEBUG = False
else:
raise WhereTheHellIsThisServedException()
Mente voi, si potrebbe anche preferire di fare questo controllo con le variabili d'ambiente come suggerisce @Soviut. Ma come qualcuno in via di sviluppo su Windows e Linux in servizio sulla verifica dei percorsi dei file era semplicemente più facile che andare con le variabili d'ambiente.
Mi sono imbattuto in questo problema proprio ora e ho finito per scrivere una soluzione simile a quella di Aryeh Leib Taurog.La mia differenza principale è che voglio distinguere tra ambienti di produzione e di sviluppo quando eseguo il server, ma anche quando eseguo alcuni script una tantum per la mia app (che eseguo come DJANGO_SETTINGS_MODULE=settings python [the script] ).In questo caso, verificare semplicemente se argv[1] == runserver non è sufficiente.Quindi quello che mi è venuto in mente è passare un argomento aggiuntivo della riga di comando quando eseguo devserver, e anche quando eseguo i miei script, e cercare quell'argomento in settings.py.Quindi il codice è simile al seguente:
if '--in-development' in sys.argv:
## YES! we're in dev
pass
else:
## Nope, this is prod
pass
quindi, l'esecuzione del server Django diventa
python Manage.py runserver [qualsiasi opzione tu voglia] --in-development
ed eseguire i miei script è facile come
DJANGO_SETTINGS_MODULE=impostazioni python [myscript] --in-development
Assicurati solo che l'argomento aggiuntivo che passi non sia in conflitto con nulla di Django (in realtà utilizzo il nome della mia app come parte dell'argomento).Penso che questo sia abbastanza decente, in quanto mi consente di controllare esattamente quando il mio server e i miei script si comporteranno come prod o dev, e non mi affido alle convenzioni di nessun altro, oltre alle mie.
MODIFICARE:Manage.py si lamenta se passi opzioni non riconosciute, quindi devi modificare il codice in settings.py in modo che sia qualcosa di simile
if sys.argv[0] == 'manage.py' or '--in-development' in sys.argv:
# ...
pass
Anche se funziona, riconosco che non è la soluzione più elegante...
Se si desidera passare le impostazioni del file automaticamente dipende l'ambiente runtime si potrebbe utilizzare qualcosa che si differenzia in environ, per es.
from os import environ
if environ.get('_', ''):
print "This is dev - not Apache mod_wsgi"
settings.DEBUG potrebbe essere vero e in esecuzione in qualche altro server non-sviluppo Apache o. Sarà ancora correre. Per quanto posso dire, non v'è nulla nell'ambiente breve run-time di esaminare il pid e il confronto al pid del sistema operativo che vi darà questa informazione.
Una differenza tra lo sviluppo e l'ambiente di distribuzione sarà il server che è in esecuzione su. Che cosa è esattamente diverso dipenderà dalla vostra ambienti dev e la distribuzione.
Conoscere il proprio dev e distribuire gli ambienti, le variabili di richiesta HTTP potrebbero essere utilizzati per distinguere tra i due. Guardate variabili di richiesta come request.META.HTTP_HOST, request.META.SERVER_NAME e request.META.SERVER_PORT e confrontarli nei due ambienti.
Scommetto che troverete qualcosa del tutto evidente che è diverso e può essere utilizzato per rilevare l'ambiente di sviluppo. Fai il test in settings.py e impostare una variabile che è possibile utilizzare altrove.
Io uso:
DEV_SERVERS = [
'mymachine.local',
]
DEVELOPMENT = platform.node() in DEV_SERVERS
che richiede prestare attenzione a ciò che viene restituito da .node() sulle vostre macchine. E 'importante che il default sia non-sviluppo, in modo da non esporre accidentalmente le informazioni sensibili di sviluppo.
Si potrebbe anche prendere in considerazione modi più complicati di identificare in modo univoco i computer .
Ispirato dalla risposta di Aryeh, il trucco ho ideato per mio uso è quello di guardare solo per il nome del mio script di gestione in sys.argv[0]:
USING_DEV_SERVER = "pulpdist/manage_site.py" in sys.argv[0]
(Il mio caso l'uso è quello di attivare automaticamente l'autenticazione nativa Django quando si esegue il server di prova - durante l'esecuzione in Apache, anche sui server di sviluppo, tutta l'autenticazione per il mio progetto attuale è gestita tramite Kerberos)
È possibile determinare se si sta eseguendo in WSGI (mod_wsgi, gunicorn, cameriera, ecc) vs. manage.py (runserver, prova, migrare, etc.) o qualsiasi altra cosa:
import sys
WSGI = 'django.core.wsgi' in sys.modules
Si potrebbe verificare il valore request.META["SERVER_SOFTWARE"]:
dev_servers = ["WSGIServer", "Werkzeug"]
if any(server in request.META["SERVER_SOFTWARE"] for server in dev_servers):
print("is local")
