¿Cómo puedo estar seguro de que mi aplicación se ejecuta en el servidor de desarrollo o no? Supongo que podría verificar el valor de settings.DEBUG y asumir que DEBUG es True y luego se está ejecutando en el servidor de desarrollo, pero preferiría saber con certeza que confiar en la convención.¿Cómo puedo saber si mi aplicación Django se ejecuta en el servidor de desarrollo o no?
server = request.META.get('wsgi.file_wrapper', None)
if server is not None and server.__module__ == 'django.core.servers.basehttp':
print('inside dev')
Por supuesto, wsgi.file_wrapper podrían fijarse sobre META, y tienen una clase de un módulo denominado django.core.servers.basehttp por coincidencia extrema en otro entorno de servidor, pero espero que esto tendrá cubierto.
Por cierto, he descubierto esto haciendo una plantilla syntatically no válida mientras se ejecuta en el servidor de desarrollo, y buscó cosas interesantes en las secciones Traceback y la Request information, así que sólo estoy editando mi respuesta para corroborar con las ideas de Nate .
configuraciones ..DE ERROR podría ser Verdadero y ejecutarse bajo Apache u otro servidor que no sea de desarrollo. Todavía se ejecutará. Por lo que puedo decir, no hay nada en el entorno de tiempo de ejecución salvo para examinar el pid y compararlo con los pids en el SO que le proporcionarán esta información.
Una diferencia entre el entorno de desarrollo y despliegue va a ser el servidor en el que se está ejecutando. Lo que es exactamente diferente dependerá de sus entornos de desarrollo y desarrollo.
Conociendo sus propios entornos de despliegue e implementación, las variables de solicitud de HTTP podrían usarse para distinguir entre los dos. Mire request variables como request.META.HTTP_HOST, request.META.SERVER_NAME y request.META.SERVER_PORT y compárelos en los dos entornos.
Apuesto a que encontrará algo bastante obvio que es diferente y se puede utilizar para detectar su entorno de desarrollo. Realice la prueba en settings.py y establezca una variable que pueda usar en cualquier otro lugar.
Normalmente configuré una variable llamada environment y la configuré en "DESARROLLO", "ESCENARIO" o "PRODUCCIÓN". Dentro del archivo de configuración, puedo agregar lógica básica para cambiar las configuraciones que se utilizan, según el entorno.
EDIT: Además, simplemente puede utilizar esta lógica para incluir diferentes archivos settings.py que anulan la configuración básica. Por ejemplo:
if environment == "DEBUG":
from debugsettings import *
Basándose en settings.DEBUG es la más elegante manera AFAICS ya que también se utiliza en Django base de código en alguna ocasión.
Supongo que lo que realmente quiere es una forma de establecer esa bandera automáticamente sin necesidad de actualizarla manualmente cada vez que carga el proyecto a los servidores de producción.
Para comprobar que el camino de la settings.py (en settings.py) para determinar qué servidor del proyecto se está ejecutando en:
if __file__ == "path to settings.py in my development machine":
DEBUG = True
elif __file__ in [paths of production servers]:
DEBUG = False
else:
raise WhereTheHellIsThisServedException()
Eso sí, también puede ser que prefiera hacer esta comprobación con las variables de entorno como @Soviut sugiere. Pero como alguien que está desarrollando en Windows y sirviendo en Linux verificando las rutas de los archivos era más fácil que ir con variables de entorno.
bien, aparte de las ocasiones en que podría adoptar la misma convención de ruta en el desarrollo y la producción (que vencería esto), este parece ser el mejor para yo. y +1 para 'WhereTheHellIsThisServedException' :-) – nemesisfixx
Puse lo siguiente en mi configuración.py distinguir entre el servidor dev estándar y producción:
import sys
RUNNING_DEVSERVER = (len(sys.argv) > 1 and sys.argv[1] == 'runserver')
Esto también se basa en la convención, sin embargo.
(modificada por el comentario de Daniel Magnusson)
tuve que agregar si len (sys.argv)> 1: en el servidor de prod para que funcione. –
Esta es la mejor respuesta ya que no requiere una solicitud. Quiero hacer esto para conectar condicionalmente las urls de los medios –
¿Podría explicarme para qué sirve esto? Tal vez no entiendo el problema, pero esta variable almacena si se llama al sitio con manage.py runserver, ¿verdad? ¿Y qué haces con esto? Me tropiezo con esta publicación y esto parece algo nuevo que quiero aprender. Estaba buscando una manera de detectar si estoy en localhost, en ese caso activar DEBUG (no estoy buscando una respuesta sobre esto en esta publicación) – aless80
me encontré con este problema en este momento, y terminó escribiendo una solución similar a Aryeh Leib de Taurog. Mi diferencia principal es que quiero diferenciar entre un entorno de producción y un entorno de desarrollo cuando ejecuto el servidor, pero también cuando ejecuto algunos scripts únicos para mi aplicación (que ejecuto como DJANGO_SETTINGS_MODULE = settings python [el script]). En este caso, simplemente mirando si argv [1] == runserver no es suficiente. Entonces, lo que se me ocurre es pasar un argumento de línea de comando adicional cuando ejecuto el servidor dev, y también cuando ejecuto mis scripts, y simplemente busco ese argumento en settings.py. Por lo que el código es el siguiente:
if '--in-development' in sys.argv:
## YES! we're in dev
pass
else:
## Nope, this is prod
pass
continuación, se ejecuta el servidor Django vuelve
python manage.py runserver [cualquiera de las opciones que desee] --en desarrollo
y pasando mis guiones se tan fácil como
DJANGO_SETTINGS_MODULE = configuración pitón [miscript] --en desarrollo
Sólo asegúrese de que el argumento extra que pase a lo largo de Doens Conflicto con cualquier cosa django (en realidad uso el nombre de mi aplicación como parte del argumento). Creo que esto es bastante decente, ya que me permite controlar exactamente cuándo mi servidor y mis scripts se comportarán como prod o dev, y no estoy confiando en las convenciones de nadie más, aparte de la mía.
EDIT: manage.py se queja si pasa opciones no reconocidas, por lo que es necesario cambiar el código en settings.py a ser algo así como
if sys.argv[0] == 'manage.py' or '--in-development' in sys.argv:
# ...
pass
Aunque esto funciona, reconozco que no es el más elegante de soluciones ...
Inspirado por la respuesta de Aryeh, el truco ideé para mi propio uso es sólo tiene que buscar el nombre de mi script de gestión de sys.argv[0]:
USING_DEV_SERVER = "pulpdist/manage_site.py" in sys.argv[0]
(Mi caso de uso es para habilitar automáticamente la autenticación nativa Django cuando se ejecuta el servidor de prueba - cuando se ejecuta en Apache, incluso en servidores de desarrollo, toda la autenticación para mi proyecto actual se maneja a través de Kerberos)
que utilizo:
DEV_SERVERS = [
'mymachine.local',
]
DEVELOPMENT = platform.node() in DEV_SERVERS
que requiere prestar atención a lo que devuelve .node() en sus máquinas. Es importante que el valor predeterminado no sea de desarrollo para no exponer accidentalmente la información de desarrollo sensible.
También puede consultar more complicated ways of uniquely identifying computers.
Si quiere cambiar sus archivos de configuración automáticamente dependiendo del entorno de tiempo de ejecución , puede usar algo que difiera en el entorno, p.
from os import environ
if environ.get('_', ''):
print "This is dev - not Apache mod_wsgi"
Por lo general, esto funciona:
import sys
if 'runserver' in sys.argv:
# you use runserver
Puede determinar si se está ejecutando bajo WSGI (mod_wsgi, gunicorn, camarera, etc.) vs. manage.py (de ejecución del servidor, prueba, emigran, etc.) o cualquier otra cosa:
import sys
WSGI = 'django.core.wsgi' in sys.modules
+1 para realmente tratar de abordar la cuestión es decir, detectar qué servidor está sirviendo la aplicación de Django, en lugar de depender de la configuración. Por ejemplo, no hay nada que impida que alguien se ejecute en el modo DEPURAR detrás de algo que no sea el servidor web de desarrollo. –
Otro campo de META que es específico para el servidor de desarrollo: SERVER_SOFTWARE tiene las cadenas 'WSGIServer' y' Python' en el desarrollador y todo lo que configure en su servidor HTTP en "implementado". – zgoda
Agregaría un 'getattr (servidor, '__module__', Ninguno)' en la segunda línea en lugar de ir directamente a la notación de puntos. Nunca se sabe ... –