¿Cómo puedo saber si mi aplicación Django se está ejecutando en el servidor de desarrollo o no?

Question

¿Cómo puedo estar seguro de que mi aplicación se ejecuta en el servidor de desarrollo o no? Supongo que podría comprobar valor de settings.DEBUG y asumir si se DEBUG True entonces se ejecuta en el servidor de desarrollo, pero yo prefiero saber con seguridad de confiar en la convención.

Answer 1

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ía estar situado en 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, descubrí esto haciendo una plantilla syntatically no válida mientras se ejecuta en el servidor de desarrollo, y busqué cosas interesantes en el Traceback y las secciones Request information, así que sólo estoy editando mi respuesta para corroborar con las ideas de Nate.

Answer 2

pongo el siguiente en mi settings.py de 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)

Answer 3

Normalmente puedo configurar una variable llamada environment y la ajuste en "desarrollo", "puesta en escena" o "producción". Dentro del archivo de configuración, entonces puedo añadir lógica básica para cambiar la configuración de la que se están utilizando, basado en el medio ambiente.

EDIT: Además, puede simplemente usar esta lógica para incluir diferentes archivos settings.py que anulan los ajustes de la base. Por ejemplo:

if environment == "DEBUG":
    from debugsettings import *

Answer 4

Por lo general, esto funciona:

import sys

if 'runserver' in sys.argv:
    # you use runserver

Answer 5

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 manera de establecer que la bandera de forma automática sin necesidad de actualizar manualmente cada vez que se 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 podría preferir hacer esta comprobación con las variables de entorno como sugiere @Soviut. Pero como alguien desarrollar en Windows y en Linux que sirve de comprobar las rutas de archivos era evidente más fácil que ir con las variables de entorno.

Answer 6

Me encontré con este problema en este momento, y terminé escribiendo una solución similar a Aryeh Leib de Taurog. Mi principal diferencia es que quiero diferenciar entre una producción y entornos dev cuando se ejecuta el servidor, sino también cuando se ejecuta algunos scripts de una sola vez para mi aplicación (que corro como DJANGO_SETTINGS_MODULE = configuración pitón [el guión]). En este caso, basta con observar si el argv [1] == ejecución del servidor no es suficiente. Así que lo que ocurrió con es pasar un argumento extra de línea de comandos al ejecutar el devserver, y también cuando corro mis guiones, y sólo tiene que buscar 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

A continuación, se ejecuta el servidor Django vuelve

python manage.py runserver [cualquiera de las opciones que desee] --en desarrollo

y ejecutar mis guiones es 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 conflicto doens't con Django nada (en realidad, yo uso el nombre de mi aplicación como parte del argumento). Creo que esto es bastante bueno, ya que me permite controlar exactamente cuándo mi servidor y secuencias de comandos se comportarán como prod o dev, y no voy a confiar en cualquier otra persona de convenciones, que no sea la mía.

EDIT: manage.py se queja si pasa opciones no reconocidas, por lo que necesita para 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

A pesar de esto funciona, reconozco que no es el más elegante de soluciones ...

Answer 7

Si desea cambiar la configuración de los archivos dependientes automáticamente en el entorno de ejecución usted podría utilizar algo que difiere en Environ, por ejemplo.

from os import environ
if environ.get('_', ''): 
    print "This is dev - not Apache mod_wsgi"         

Answer 8

settings.DEBUG podría ser verdad y se corre sobre Apache o algún otro servidor que no sea el desarrollo. Todavía se ejecutará. Por lo que yo puedo decir, no hay nada en el medio ambiente a corto tiempo de ejecución de examinar el pid y comparando con los PID en el sistema operativo que le dará esta información.

Answer 9

Una diferencia entre el desarrollo y el entorno de despliegue va a ser el servidor que se está ejecutando. ¿Qué es exactamente diferente dependerá de sus entornos dev e implementación.

Conocer su propio dev y desplegar entornos, las variables de peticiones HTTP podrían ser utilizados para distinguir entre los dos. Mira variables de petición como request.META.HTTP_HOST, request.META.SERVER_NAME y request.META.SERVER_PORT y compararlas en los dos entornos.

apuesto a que encontrará algo bastante obvio que es diferente y se puede utilizar para detectar su entorno de desarrollo. Hacer la prueba en settings.py y establecer una variable que se puede utilizar en otros lugares.

Answer 10

Yo uso:

DEV_SERVERS = [
    'mymachine.local',
]

DEVELOPMENT = platform.node() in DEV_SERVERS

que requiere prestar atención a lo que se devuelve por .node() en sus máquinas. Es importante que el defecto sea no-desarrollo, de modo que no se expone accidentalmente información sobre el desarrollo sensible.

También podría mirar en formas más complicadas de identificar de forma única los ordenadores .

Answer 11

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)

Answer 12

Se puede determinar si se está ejecutando bajo WSGI (mod_wsgi, gunicorn, camarera, etc.) vs. manage.py (de ejecución del servidor, prueba, migrar, etc.) o cualquier otra cosa:

import sys
WSGI = 'django.core.wsgi' in sys.modules

Answer 13

Usted puede comprobar el valor request.META["SERVER_SOFTWARE"]:

dev_servers = ["WSGIServer", "Werkzeug"]
if any(server in request.META["SERVER_SOFTWARE"] for server in dev_servers):
    print("is local")