django-admin y manage.py¶django-admin es la herramienta de línea de comandos de Django para tareas administrativas. Este documento describe todo lo que puede hacer.
Además, manage.py se crea automáticamente en cada proyecto de Django. Hace lo mismo que django-admin pero también establece la variable de entorno DJANGO_SETTINGS_MODULE para que apunte al archivo settings.py del proyecto.
El script django-admin debería estar en el camino de sistema si instalaste Django mediante pip. Si no está en tu ruta, asegúrate de tener activado tu entorno virtual.
En general, cuando trabajas en un solo proyecto de Django, es más fácil utilizar manage.py que django-admin. Si necesitas cambiar entre múltiples archivos de configuración de Django, utiliza django-admin con DJANGO_SETTINGS_MODULE o la opción de línea de comandos --settings.
Los ejemplos de línea de comandos en este documento utilizan django-admin para ser consistentes, pero cualquier ejemplo puede utilizar manage.py o python -m django igualmente bien.
$ django-admin <command> [options]
$ manage.py <command> [options]
$ python -m django <command> [options]
command debería ser uno de los comandos listados en este documento. options, que es opcional, deberían ser cero o más opciones disponibles para el comando dado.
Ejecuta django-admin help para mostrar información sobre la utilización y una lista de los comandos proporcionados por cada aplicación.
Ejecuta django-admin help --commands para mostrar una lista de todos los comandos disponibles.
Run django-admin help <comando> para mostrar una descripción del comando y una lista de sus opciones disponibles.
Muchas comandos aceptan una lista de «nombres de aplicación». Un «nombre de aplicación» es la parte básica del nombre del paquete que contiene tus modelos. Por ejemplo, si tu INSTALLED_APPS contiene la cadena 'mysite.blog', el nombre de aplicación es blog.
Run django-admin version para mostrar la versión actual de Django.
La salida sigue el esquema descrito en PEP 440.
1.4.dev17026
1.4a1
1.4
Utiliza la opción --verbosity, donde esté disponible, para especificar la cantidad de notificaciones e información de depuración que django-admin imprime en la consola.
Usa el marco de trabajo de comprobación del sistema para inspeccionar todo el proyecto Django por problemas comunes.
Por defecto, se verificarán todas las aplicaciones. Puedes verificar un subconjunto de aplicaciones proporcionando una lista de etiquetas de aplicación como argumentos:
django-admin check auth admin myapp
El marco de trabajo de comprobación del sistema realiza muchos tipos diferentes de comprobaciones que están categorizadas con etiquetas. Puedes utilizar estas etiquetas para restringir las comprobaciones realizadas a solo aquellas en una categoría particular. Por ejemplo, para realizar solo comprobaciones de modelos y compatibilidad, ejecuta:
django-admin check --tag models --tag compatibility
Specifica la base de datos para ejecutar comprobaciones que requieren acceso a la base de datos:
django-admin check --database default --database other
Por defecto, estas comprobaciones no se ejecutarán.
Lista todas las etiquetas disponibles.
Activa algunas comprobaciones adicionales que solo son relevantes en un entorno de despliegue.
Puedes utilizar esta opción en tu entorno de desarrollo local, pero ya que el módulo de configuración de tus entornos de desarrollo locales puede no tener muchos de los ajustes de producción, probablemente querrás apuntar la orden check a un módulo de configuración diferente, ya sea estableciendo la variable de entorno DJANGO_SETTINGS_MODULE o pasando la opción --settings:
django-admin check --deploy --settings=production_settings
O podrías ejecutarlo directamente en una despliegue de producción o staging para verificar que se están utilizando los ajustes correctos (omitir --settings). Incluso podrías incluirlo en tu suite de pruebas de integración.
Specifica el nivel de mensaje que causará la orden a salir con un estado no cero. Por defecto es ERROR.
compilemessages¶Compila los archivos .po creados por makemessages a archivos .mo para su uso con el soporte de gettext integrado. Consulta la sección Internacionalización y localización.
Especifica las localizaciones(s) que procesar. Si no se proporciona, todas las localizaciones se procesan.
Especifica las localizaciones(s) que excluir del proceso. Si no se proporciona, ninguna localización está excluida.
Incluye traducciones fuzzy en los archivos compilados.
Ejemplo de uso:
django-admin compilemessages --locale=pt_BR
django-admin compilemessages --locale=pt_BR --locale=fr -f
django-admin compilemessages -l pt_BR
django-admin compilemessages -l pt_BR -l fr --use-fuzzy
django-admin compilemessages --exclude=pt_BR
django-admin compilemessages --exclude=pt_BR --exclude=fr
django-admin compilemessages -x pt_BR
django-admin compilemessages -x pt_BR -x fr
Ignora directorios que coincidan con el patrón de estilo glob dado. Utiliza varias veces para ignorar más.
Ejemplo de uso:
django-admin compilemessages --ignore=cache --ignore=outdated/*/locale
createcachetable¶Crea las tablas de caché para su uso con la parte trasera de caché de base de datos utilizando la información de tu archivo de configuración. Consulta la sección Marco de caché de Django para obtener más información.
Especifica la base de datos en la que se crearán las tabla(s) de caché. Por defecto es default.
Imprime el SQL que se ejecutaría sin ejecutarlo realmente, para que puedas personalizarlo o utilizar el marco de migraciones.
dbshell¶Ejecuta el cliente de línea de comandos para el motor de base de datos especificado en tu configuración ENGINE, con los parámetros de conexión especificados en tus configuraciones USER, PASSWORD, etc.
Para PostgreSQL, ejecuta el cliente de línea de comandos psql.
Para MySQL, ejecuta el cliente de línea de comandos mysql.
Para SQLite, ejecuta el cliente de línea de comandos sqlite3.
Para Oracle, ejecuta el cliente de línea de comandos sqlplus.
Esta orden asume que los programas están en tu PATH, por lo que una llamada al nombre del programa (psql, mysql, sqlite3, sqlplus) encontrará el programa en el lugar correcto. No hay forma de especificar manualmente la ubicación del programa.
Especifica la base de datos a la que abrir una consola. Por defecto, es default.
Cualquier argumento posterior a un divisor -- se pasarán al cliente de línea de comandos subyacente. Por ejemplo, con PostgreSQL puedes utilizar la bandera -c del comando psql para ejecutar una consulta SQL directamente:
$ django-admin dbshell -- -c 'select current_user'
current_user
--------------
postgres
(1 row)
En MySQL/MariaDB, puedes hacer esto utilizando la bandera -e del comando mysql:
$ django-admin dbshell -- -e "select user()"
+----------------------+
| user() |
+----------------------+
| djangonaut@localhost |
+----------------------+
diffsettings¶Muestra las diferencias entre el archivo de configuración actual y los valores predeterminados de Django (o otro archivo de configuración especificado mediante la opción --default).
Los parámetros que no aparecen en los valores predeterminados están seguidos por "###". Por ejemplo, los valores predeterminados no definen ROOT_URLCONF, por lo que ROOT_URLCONF está seguido de "###" en la salida de diffsettings.
Muestra todos los parámetros, incluso si tienen el valor predeterminado de Django. Dichos parámetros están precedidos por "###".
El módulo de configuración que se debe comparar con la configuración actual. Deja vacío para comparar con los valores predeterminados de Django.
Especifica el formato de salida. Los valores disponibles son hash y unified. hash es el modo por defecto que muestra la salida descrita anteriormente. unified muestra la salida similar a diff -u. Los valores predeterminados están precedidos por un signo menos, seguidos del parámetro modificado precedido de un signo más.
dumpdata¶Muestra en la salida estándar todos los datos en la base de datos asociados con el nombre de aplicación especificado (o aplicaciones).
Si no se proporciona ningún nombre de aplicación, se dumpearán todas las aplicaciones instaladas.
El resultado de dumpdata se puede utilizar como entrada para loaddata.
Cuando el resultado de dumpdata se almacena en un archivo, puede servir como una ficha para pruebas o como datos iniciales iniciales.
Ten en cuenta que dumpdata utiliza el administrador predeterminado del modelo para seleccionar los registros a exportar. Si estás utilizando un administrador personalizado como administrador predeterminado y este filtra algunos de los registros disponibles, no se exportarán todos los objetos.
Utiliza el administrador base de Django, exportando registros que podrían estar filtrados o modificados por un administrador personalizado.
Especifica el formato de serialización del resultado. Por defecto es JSON. Los formatos admitidos se enumeran en formatos de serialización.
Especifica el número de espacios de indentación a utilizar en la salida. Por defecto es None que muestra todos los datos en una sola línea.
Previne la exportación de aplicaciones o modelos específicos (especificados en la forma app_label.ModelName). Si especificas un nombre de modelo, solo ese modelo se excluirá, en lugar del toda la aplicación. También puedes mezclar nombres de aplicación y modelos.
Si deseas excluir varias aplicaciones, pasa --exclude más de una vez:
django-admin dumpdata --exclude=auth --exclude=contenttypes
Especifica la base de datos desde la que se exportarán los datos. Por defecto es default.
Utiliza el método del modelo natural_key() para serializar cualquier clave foránea y relación muchos-a-muchos a objetos del tipo que define el método. Si estás exportando objetos de permisos Permission o ContentType de contrib.auth o contrib.contenttypes, probablemente debes utilizar esta bandera. Consulta la documentación sobre claves naturales para obtener más detalles sobre esto y la siguiente opción.
Omite la clave primaria en los datos serializados de este objeto ya que se puede calcular durante la deserialización.
Sólo se muestran los objetos especificados por una lista separada por comas de claves primarias. Esto solo está disponible cuando se exporta un modelo. Por defecto, se muestran todos los registros del modelo.
Especifica un archivo para escribir los datos serializados. Por defecto, la data va a la salida estándar.
Cuando esta opción está configurada y --verbosity es mayor que 0 (el valor por defecto), se muestra una barra de progreso en el terminal.
El archivo de salida puede ser comprimido con uno de los formatos bz2, gz, lzma o xz al finalizar el nombre del archivo con la correspondiente extensión. Por ejemplo, para exportar los datos como un archivo JSON comprimido:
django-admin dumpdata -o mydata.json.gz
flush¶Elimina todos los datos de la base de datos y re ejecuta cualquier manipulador post-sincronización. La tabla que indica las migraciones aplicadas no se limpia.
Si prefieres empezar desde una base de datos vacía y volver a ejecutar todas las migraciones, deberías borrar y recrear la base de datos y luego ejecutar migrate en su lugar.
Suprime todos los prompts del usuario.
Specifies el base de datos a vaciar. Por defecto es default.
Introspecciona las tablas de la base de datos apuntada por la configuración NAME y produce un módulo de modelo Django (un archivo models.py) en salida estándar.
Puedes elegir qué tablas o vistas inspeccionar pasando sus nombres como argumentos. Si no se proporcionan argumentos, se crean modelos para las vistas si se utiliza la opción --include-views. Los modelos de particiones se crean en PostgreSQL si se utiliza la opción --include-partitions.
Utiliza esto si tienes una base de datos legada con la que deseas utilizar Django. El script inspeccionará la base de datos y creará un modelo para cada tabla dentro de ella.
Como podrías esperar, los modelos creados tendrán un atributo para cada campo en la tabla. Ten en cuenta que inspectdb tiene unos pocos casos especiales en su salida de nombres de campos:
Si inspectdb no puede mapear el tipo de columna a un tipo de campo del modelo, utilizará TextField y insertará el comentario de Python 'Este tipo de campo es una suposición.' junto al campo en el modelo generado. Los campos reconocidos pueden depender de las aplicaciones listadas en INSTALLED_APPS. Por ejemplo, la aplicación django.contrib.postgres agrega la reconocimiento para varios tipos de campos específicos de PostgreSQL.
Si el nombre de columna de la base de datos es una palabra reservada de Python (como 'pass', 'class' o 'for'), inspectdb agregará '_field' al nombre del atributo. Por ejemplo, si una tabla tiene una columna 'for', el modelo generado tendrá un campo 'for_field', con la propiedad db_column establecida en 'for'. inspectdb insertará el comentario de Python 'El campo se ha renombrado porque era una palabra reservada de Python.' junto al campo.
Esta característica está pensada como un atajo, no como la generación definitiva de modelos. Después de ejecutarlo, querrás revisar los modelos generados tú mismo para hacer personalizaciones. En particular, necesitarás reorganizar el orden de los modelos, para que los modelos que se refieren a otros modelos estén ordenados correctamente.
Django no crea valores por defecto de la base de datos cuando un campo de modelo tiene especificado default. De manera similar, los valores por defecto de la base de datos no se traducen en valores por defecto de campos de modelo ni se detectan de ninguna forma por inspectdb.
Por defecto, inspectdb crea modelos no administrados. Es decir, managed = False en el atributo Meta del modelo le dice a Django que no gestione la creación, modificación y eliminación de cada tabla. Si deseas permitir que Django gestione el ciclo de vida de la tabla, necesitarás cambiar la opción managed a True (o eliminarla porque True es su valor por defecto).
Los modelos se crean para vistas materializadas si se utiliza el parámetro –include-views.
Se crean modelos para tablas extranjeras.
Los modelos se crean para vistas materializadas si se utiliza el parámetro –include-views.
Se crean modelos para tablas particionadas si se utiliza el parámetro –include-partitions.
Specifica la base de datos a introspeccionar. Por defecto es default.
Si se proporciona este parámetro, también se crean modelos para particiones.
Solo se implementa el soporte para PostgreSQL.
Si se proporciona este parámetro, también se crean modelos para vistas de la base de datos.
loaddata¶Busca y carga los contenidos del fixture especificado en la base de datos.
Specifies the database into la que se cargará los datos. Por defecto, es default.
Ignora campos y modelos que pueden haber sido eliminados desde que el archivo de fijación fue generado originalmente.
Specifica una aplicación única a buscar fijaciones en lugar de buscarlas en todas las aplicaciones.
Specifica el formato de serialización formato de serialización (por ejemplo, json o xml) para fijaciones leídas desde stdin.
Excluye la carga de las fijaciones de las aplicaciones y/o modelos dadas (en forma de app_label o app_label.ModelName). Utiliza la opción varias veces para excluir más de una aplicación o modelo.
stdin¶Puedes utilizar un guión como el nombre de la fijación para cargar entrada desde sys.stdin. Por ejemplo:
django-admin loaddata --format=json -
Cuando se lee desde stdin, la opción --format es necesaria para especificar el formato de serialización del input (por ejemplo, json o xml).
La carga desde stdin es útil con las redirecciones estándar de entrada y salida. Por ejemplo:
django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -
El comando dumpdata se puede utilizar para generar la entrada para loaddata.
Ver también
Para más detalles sobre fijaciones, consulta el tema Ficheros de pruebas.
Ejecuta la búsqueda de todos los strings marcados para traducción en todo el árbol de origen del directorio actual. Crea (o actualiza) un archivo de mensajes en el directorio conf/locale (en el árbol Django) o locale (para proyecto y aplicación). Después de realizar cambios en los archivos de mensajes, debes compilarlos con compilemessages para su uso con el soporte de gettext incorporado. Consulta la documentación sobre internacionalización <how-to-create-language-files> para obtener más detalles.
Este comando no requiere configurar las opciones de settings. Sin embargo, cuando no se han configurado las opciones de settings, el comando no puede ignorar los directorios MEDIA_ROOT y STATIC_ROOT, ni incluir LOCALE_PATHS.
Actualiza los archivos de mensajes para todos los idiomas disponibles.
Especifica una lista de extensiones de archivo a examinar (por defecto: html, txt o py si se especifica el dominio como djangojs).
Ejemplo de uso:
django-admin makemessages --locale=de --extension xhtml
Separa múltiples extensiones con comas o utiliza -e o --extension varias veces:
django-admin makemessages --locale=de --extension=html,txt --extension xml
Especifica los locales(s) a procesar.
Especifica las localizaciones(s) que excluir del proceso. Si no se proporciona, ninguna localización está excluida.
Ejemplo de uso:
django-admin makemessages --locale=pt_BR
django-admin makemessages --locale=pt_BR --locale=fr
django-admin makemessages -l pt_BR
django-admin makemessages -l pt_BR -l fr
django-admin makemessages --exclude=pt_BR
django-admin makemessages --exclude=pt_BR --exclude=fr
django-admin makemessages -x pt_BR
django-admin makemessages -x pt_BR -x fr
Especifica el dominio de los archivos de mensajes. Las opciones admitidas son:
django para todos los archivos con extensiones *.py, *.html y *.txt (por defecto)
djangojs para archivos *.js
Sigue los enlaces simbólicos a directorios al buscar nuevas cadenas de traducción.
Ejemplo de uso:
django-admin makemessages --locale=de --symlinks
Ignora archivos o directorios que coincidan con el patrón dado glob-estilo. Utiliza varias veces para ignorar más.
Estos patrones se utilizan por defecto: 'CVS', '.*', '*~', '*.pyc'.
Ejemplo de uso:
django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
Deshabilita los valores predeterminados de --ignore.
Deshabilita la ruptura de líneas largas en varias líneas en archivos de idioma.
Suprime la escritura de líneas de comentario #: filename:line en archivos de idioma. Utilizar esta opción hace más difícil para los traductores técnicamente capacitados entender el contexto de cada mensaje.
Controla las líneas de comentario #: filename:line en archivos de idioma. Si la opción es:
full (el valor predeterminado si no se da): las líneas incluyen tanto el nombre del archivo como el número de línea.
file: se omite el número de línea.
never: las líneas están suprimidas (igual que --no-location).
Requiere gettext 0.19 o más reciente.
Elimina cadenas de mensajes obsoletas de los archivos .po.
Evita borrar los archivos temporales .pot generados antes de crear el archivo .po. Esto es útil para depurar errores que pueden impedir la creación de los archivos de idioma finales.
Ver también
Consulte Personalizando la orden makemessages para obtener instrucciones sobre cómo personalizar las palabras clave que makemessages pasa a xgettext.
makemigrations¶Crea nuevas migraciones basadas en los cambios detectados en tus modelos. Las migraciones, su relación con las aplicaciones y más se cubren en profundidad en la documentación de migraciones.
Proporcionando uno o varios nombres de aplicación como argumentos limitará las migraciones creadas a la(s) aplicación(es) especificada(s) y cualquier dependencia necesaria (la tabla del otro lado de un ForeignKey, por ejemplo).
Para agregar migraciones a una aplicación que no tiene un directorio migrations, ejecuta makemigrations con el etiqueta de aplicación del app.
Suprime todas las solicitudes del usuario. Si una solicitud suprimida no puede resolverse automáticamente, la orden saldrá con código de error 3.
Genera un archivo de migración vacío para las aplicaciones especificadas, para la edición manual. Esto es para usuarios avanzados y no debe usarse a menos que esté familiarizado con el formato de migración, las operaciones de migración y las dependencias entre las migraciones.
Muestra qué migraciones se harían sin escribir realmente ningún archivo de migración en disco. Usando esta opción junto con --verbosity 3 también mostrará los archivos de migración completos que se escribirían.
Habilita la resolución de conflictos de migración.
Permite nombrar las migraciones generadas en lugar de usar un nombre generado. El nombre debe ser un identificador válido de Python: identifier.
Genera archivos de migración sin encabezado de versión y fecha de Django.
Hace que makemigrations salga con un estado no cero cuando se detecten cambios en los modelos sin migraciones. Implica --dry-run.
Divierte la salida del registro y las solicitudes de entrada a stderr, escribiendo solo los caminos de los archivos de migración generados en stdout.
Combina los cambios de modelo en la última migración y optimiza las operaciones resultantes.
La migración actualizada tendrá un nombre generado. Para preservar el nombre anterior, establezca uno usando --name.
migrate¶Sincroniza el estado de la base de datos con el conjunto actual de modelos y migraciones. Las migraciones, su relación con las aplicaciones y más se cubren en profundidad en la documentación sobre migraciones.
El comportamiento de este comando cambia según los argumentos proporcionados:
Sin argumentos: Se ejecutan todas las migraciones de todas las aplicaciones.
<etiqueta_de_aplicación>: Se ejecutan las migraciones de la aplicación especificada, hasta la última migración. Esto puede implicar ejecutar las migraciones de otras aplicaciones también, debido a dependencias.
<etiqueta_de_aplicación> <nombre_de_migración>: Lleva el esquema de base de datos a un estado en que se ha aplicado la migración especificada, pero no las migraciones posteriores en la misma aplicación. Esto puede implicar desaplicar migraciones si has migrado previamente más allá de la migración especificada. Puedes usar una parte del nombre de la migración, por ejemplo 0001, siempre que sea único para el nombre de la aplicación dada. Utiliza el nombre cero para migrar todo hacia atrás es decir, para revertir todas las migraciones aplicadas para una aplicación.
Advertencia
Cuando desaplicas migraciones, también se desaplican las migraciones dependientes, sin importar <etiqueta_de_aplicación>. Puedes usar --plan para comprobar qué migraciones se desaplicarán.
Especifica la base de datos a la que migrar. Por defecto es default.
Marca las migraciones hasta la target (siguiendo las reglas anteriores) como aplicadas, pero sin ejecutar el SQL para cambiar el esquema de la base de datos.
Esto está destinado a usuarios avanzados para manipular directamente el estado de migración actual si están aplicando cambios manualmente; ten en cuenta que usar --fake corre el riesgo de poner la tabla de estado de migración en un estado en que se necesitará recuperar manualmente para hacer que las migraciones funcionen correctamente.
Permite a Django saltarse la primera migración de una aplicación si todas las tablas de base de datos con los nombres de todos los modelos creados por todas las operaciones CreateModel en esa migración ya existen. Esta opción está destinada para usar cuando se ejecutan migraciones contra una base de datos que preexiste el uso de migraciones. Sin embargo, esta opción no verifica la compatibilidad del esquema de base de datos más allá de los nombres de las tablas y por lo tanto solo es seguro utilizarla si estás seguro de que tu esquema existente coincide con lo registrado en tu primera migración.
Shows the migration operations que se realizarán para el comando migrate dado.
Permite crear tablas para aplicaciones sin migraciones. Si bien no se recomienda, el marco de trabajo de las migraciones a veces es demasiado lento en proyectos grandes con cientos de modelos.
Suprime todas las preguntas al usuario. Un ejemplo de pregunta es solicitar sobre la eliminación de tipos de contenido caducados.
Hace que migrate salga con un estado no cero cuando se detectan migraciones no aplicadas.
Elimina migraciones inexistentes de la tabla django_migrations. Esto es útil cuando los archivos de migración reemplazados por una migración cuajada han sido eliminados. Consulte Squashing Migraciones para obtener más detalles.
optimizemigration¶Optimiza las operaciones para la migración nombrada y sobreescribe el archivo existente. Si la migración contiene funciones que deben copiarse manualmente, el comando crea un nuevo archivo de migración con sufijo _optimized destinado a reemplazar la migración nombrada.
Hace que optimizemigration salga con un estado no cero cuando una migración puede ser optimizada.
Inicia un servidor web ligero de desarrollo en la máquina local. Por defecto, el servidor se ejecuta en el puerto 8000 en la dirección IP 127.0.0.1. Puedes pasar explícitamente una dirección IP y número de puerto.
Si ejecutas este script como un usuario con privilegios normales (recomendado), es posible que no tengas acceso para iniciar un puerto en un número bajo. Los números de puerto bajos están reservados para el superusuario (root).
Este servidor utiliza el objeto de aplicación WSGI especificado por la configuración WSGI_APPLICATION.
Advertencia
NO UTILICES ESTE SERVIDOR EN UN ENTORNO DE PRODUCCIÓN.
Este servidor de desarrollo ligero no ha pasado por auditorías de seguridad ni pruebas de rendimiento, por lo que es inadecuado para producción. Hacer que este servidor pueda manejar un entorno de producción está fuera del alcance de Django.
El servidor de desarrollo se recarga automáticamente el código Python para cada solicitud, según sea necesario. No necesitas reiniciar el servidor para que los cambios en el código tengan efecto. Sin embargo, algunas acciones como agregar archivos no desencadenan un reinicio, por lo que debes reiniciar el servidor en estos casos.
Si estás utilizando Linux o MacOS y has instalado tanto pywatchman como el servicio Watchman, se utilizarán señales del núcleo para recargar automáticamente el servidor (en lugar de consultar los timestamps de modificación de archivos cada segundo). Esto ofrece mejores rendimientos en proyectos grandes, una reducción del tiempo de respuesta después de cambios en el código, detección más robusta de cambios y una reducción en el consumo de energía. Django admite pywatchman 1.2.0 y versiones posteriores.
Grandes directorios con muchos archivos pueden causar problemas de rendimiento
Al utilizar Watchman con un proyecto que incluye grandes directorios no-Python como node_modules, es recomendable ignorar este directorio para obtener el mejor rendimiento. Consulta la documentación Watchman para obtener información sobre cómo hacer esto.
Tiempo de espera de Watchman
El tiempo de espera predeterminado del cliente Watchman es 5 segundos. Puedes cambiarlo estableciendo la variable de entorno DJANGO_WATCHMAN_TIMEOUT.
Cuando inicies el servidor, y cada vez que cambies código Python mientras el servidor esté en ejecución, el marco de sistema de comprobación verificará tu proyecto Django completo para algunos errores comunes (consultar la orden check :djadmin:). Si se encuentran errores, se imprimirán a la salida estándar. Puedes utilizar la opción ``--skip-checks para saltarte las comprobaciones del sistema.
Puedes ejecutar tantos servidores concurrentes como desees, siempre y cuando estén en puertos separados ejecutando django-admin runserver más de una vez.
Ten en cuenta que la dirección IP por defecto, 127.0.0.1, no es accesible desde otras máquinas en tu red. Para hacer que tu servidor de desarrollo sea visible a otras máquinas en la red, utiliza su propia dirección IP (por ejemplo, 192.168.2.1), 0 (abreviatura de 0.0.0.0), 0.0.0.0 o :: (con IPv6 habilitado).
Puedes proporcionar una dirección IP v6 rodeada de corchetes (por ejemplo, [200a::1]:8000). Esto habilitará automáticamente el soporte para IPv6.
También se puede utilizar un nombre de host que contenga solo caracteres ASCII.
Si la aplicación contributiva staticfiles está habilitada (por defecto en nuevos proyectos), el comando runserver será sobrescrito con su propio comando runserver.
La solicitud y respuesta de cada petición del servidor se envían al logger django.server.
Deshabilita el reloader automático. Esto significa que los cambios en código Python que realices mientras el servidor esté en ejecución no tendrán efecto si los módulos de Python correspondientes ya han sido cargados en memoria.
Deshabilita el uso de hilos en el servidor de desarrollo. El servidor es multihilo por defecto.
Utiliza IPv6 para el servidor de desarrollo. Esto cambia la dirección IP por defecto de 127.0.0.1 a ::1.
Por defecto, se imprime una advertencia en la consola de que runserver no es adecuado para producción:
WARNING: This is a development server. Do not use it in a production setting. Use a production WSGI or ASGI server instead.
For more information on production servers see: https://docs.djangoproject.com/en/|version|/howto/deployment/
Establece esta variable de entorno en "true" para ocultar esta advertencia.
Puerto 8000 en la dirección IP 127.0.0.1:
django-admin runserver
Puerto 8000 en la dirección IP 1.2.3.4:
django-admin runserver 1.2.3.4:8000
Puerto 7000 en la dirección IP 127.0.0.1:
django-admin runserver 7000
Puerto 7000 en la dirección IP 1.2.3.4:
django-admin runserver 1.2.3.4:7000
Puerto 8000 en la dirección IPv6 ::1:
django-admin runserver -6
Puerto 7000 en la dirección IPv6 ::1:
django-admin runserver -6 7000
Puerto 7000 en la dirección IPv6 2001:0db8:1234:5678::9:
django-admin runserver [2001:0db8:1234:5678::9]:7000
Puerto 8000 en la dirección IPv4 del host localhost:
django-admin runserver localhost:8000
Port 8000 en la dirección IPv6 del host localhost:
django-admin runserver -6 localhost:8000
Por defecto, el servidor de desarrollo no sirve ningún archivo estático para tu sitio (como archivos CSS, imágenes, cosas bajo MEDIA_URL y así sucesivamente). Si deseas configurar Django para servir medios estáticos, lee Cómo gestionar archivos estáticos (por ejemplo, imágenes, JavaScript, CSS).
El comando runserver de Django proporciona un servidor WSGI. Para ejecutar bajo ASGI necesitarás utilizar un servidor ASGI. El proyecto Daphne de Django proporciona La traducción de los textos es la siguiente: que puedes usar.
sendtestemail¶Envía un correo electrónico de prueba (para confirmar la envío de correos electrónicos a través de Django) al destinatario(s) especificado(s). Por ejemplo:
django-admin sendtestemail foo@example.com bar@example.com
Hay una pareja de opciones, y puedes usar cualquier combinación de ellas juntas:
Envía los direcciones de correo electrónico especificadas en MANAGERS utilizando mail_managers().
Envía las direcciones de correo electrónico especificadas en ADMINS utilizando mail_admins().
shell¶Inicia el intérprete interactivo de Python.
Todos los modelos de las aplicaciones instaladas se importan automáticamente en el entorno del shell. Los modelos de las aplicaciones listadas anteriormente en INSTALLED_APPS tienen prioridad. Para una --verbosity de 2 o superior, los objetos importados automáticamente se listarán. Para deshabilitar la importación automática por completo, utilice la bandera --no-imports.
Consulte la guía sobre personalizar este comportamiento para agregar o eliminar importaciones automáticas.
La importación de modelos automatizada se agregó.
Specifica el shell a utilizar. Por defecto, Django utilizará IPython o bpython si alguno de ellos está instalado. Si ambos están instalados, especifique cuál quieres como se muestra a continuación:
IPython:
django-admin shell -i ipython
bpython:
django-admin shell -i bpython
Si tienes un «rich» shell instalado pero deseas forzar el uso del intérprete de Python «plain», utilice python como nombre de interfaz, como se muestra a continuación:
django-admin shell -i python
Deshabilita la lectura del script de inicio para el intérprete de Python «plain». Por defecto, se lee el script apuntado por la variable de entorno PYTHONSTARTUP o el script ~/.pythonrc.py.
Desabilita la importación automática de modelos desde INSTALLED_APPS.
Te permite pasar una orden como cadena para ejecutarla como Django, de esta manera.
django-admin shell --command="import django; print(django.__version__)"
También puedes pasar código en la entrada estándar para ejecutarlo. Por ejemplo:
$ django-admin shell <<EOF
> import django
> print(django.__version__)
> EOF
En Windows, el REPL se produce debido a las limitaciones de implementación de select.select() en esa plataforma.
showmigrations¶Muestra todas las migraciones de un proyecto. Puedes elegir entre dos formatos:
Lista todas las aplicaciones que conoce Django, las migraciones disponibles para cada aplicación y si cada migración está aplicada (indicado por una [X] al lado del nombre de la migración). Si el nivel de verbosidad es 2 o superior, también se muestran los fechas de aplicación.
También se incluyen las aplicaciones sin migraciones, pero con (no migrations) impreso debajo de ellas.
Este es el formato de salida por defecto.
Muestra el plan de migración que seguirá Django para aplicar las migraciones. Al igual que --list, las migraciones aplicadas están marcadas con una [X]. Si el nivel de verbosidad es 2 o superior, también se muestran todas las dependencias de cada migración.
Los textos traducidos son:
Specifica la base de datos a examinar. Por defecto es default.
sqlflush¶Imprime las sentencias SQL que se ejecutarían para el comando flush.
Specifica la base de datos para la que imprimir las sentencias SQL. Por defecto es default.
sqlmigrate¶Imprime la SQL para la migración nombrada. Esto requiere una conexión activa a la base de datos, que utilizará para resolver los nombres de restricción; esto significa que debes generar la SQL contra una copia de la base de datos en la que más tarde se aplicará.
Ten en cuenta que sqlmigrate no coloriza su salida.
Genera la SQL para desaplicar la migración. Por defecto, la SQL creada es para ejecutar la migración en la dirección del avance.
Specifica la base de datos para la que generar la SQL. Por defecto es default.
sqlsequencereset¶Imprime las sentencias SQL para restablecer secuencias para el nombre de aplicación(s) dado(s).
Las secuencias son índices utilizados por algunos motores de base de datos para rastrear el número disponible siguiente para campos incrementados automáticamente.
Utilice este comando para generar SQL que fije casos donde una secuencia está desfasada con respecto a sus datos de campo incrementado automáticamente.
Specifica la base de datos para la que imprimir las sentencias SQL. Por defecto es default.
squashmigrations¶Combina las migraciones para app_label hasta y incluyendo migration_name hacia abajo en menos migraciones, si es posible. Las migraciones combinadas resultantes pueden vivir junto a las no combinadas de manera segura. Para obtener más información, por favor lea Squashing Migraciones.
Cuando se da start_migration_name, Django solo incluirá migraciones que comiencen desde y hasta esta migración. Esto ayuda a mitigar la limitación de combinación de migraciones de las operaciones RunPython y django.db.migrations.operations.RunSQL.
Deshabilita el optimizador al generar una migración combinada. Por defecto, Django intentará optimizar las operaciones en sus migraciones para reducir el tamaño del archivo resultante. Utilice esta opción si este proceso falla o crea migraciones incorrectas, aunque también por favor informe un bug de Django sobre el comportamiento, ya que la optimización está diseñada para ser segura.
Suprime todos los prompts del usuario.
Establece el nombre de la migración combinada. Cuando se omite, el nombre se basa en la primera y última migración, con _squashed_ entre ellas.
Genera archivo de migración combinada sin encabezado de versión de Django y timestamp.
startapp¶Crea la estructura de directorio para el nombre del aplicativo dado en el directorio actual o en el destino dado.
Por defecto, el nuevo directorio contiene un archivo models.py y otros archivos de plantilla de aplicación. Si solo se da el nombre del aplicativo, el directorio de la aplicación se creará en el directorio de trabajo actual.
Si se proporciona el destino opcional, Django utilizará ese directorio existente en lugar de crear uno nuevo. Puedes usar “.” para denotar el directorio de trabajo actual.
Ejemplo:
django-admin startapp myapp /Users/jezdez/Code/myapp
Proporciona la ruta a un directorio con un archivo de plantilla de aplicación personalizado o una ruta a un archivo comprimido (.tar) o un archivo comprimido (.tar.gz, .tar.bz2, .tar.xz, .tar.lzma, .tgz, .tbz2, .txz, .tlz, .zip) que contenga los archivos de plantilla de aplicación.
Por ejemplo, esto buscaría una plantilla de aplicación en el directorio dado al crear la aplicación myapp:
django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp
Django también acepta URLs (http, https, ftp) a archivos comprimidos con los archivos de plantilla de aplicación, descargándolos y extrayéndolos en tiempo real.
Por ejemplo, aprovechando la característica de GitHub para exponer repositorios como archivos zip, puedes usar una URL como:
django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/main.zip myapp
Advertencia
Las plantillas proporcionadas mediante --template se utilizan tal cual. Las plantillas maliciosas o mal construidas pueden introducir debilidades de seguridad o comportamiento no intencionado. Los archivos comprimidos también pueden consumir recursos excesivos durante la extracción, lo que puede causar crash o bloqueos.
Los contenidos de las plantillas deben ser inspeccionados cuidadosamente antes de su uso.
Especifica qué extensiones de archivo en la plantilla del aplicativo deben ser renderizadas con el motor de plantillas. Por defecto, es py.
Especifica qué archivos en el plantilla del aplicativo (además de aquellos que coincidan con –extension) deben ser renderizados con el motor de plantillas. Por defecto, es una lista vacía.
Especifica qué directorios en la plantilla de la aplicación deben excluirse, además de `.git` y `__pycache__` . Si no se proporciona esta opción, los directorios llamados `__pycache__` o que comienzan con . serán excluidos.
La contexto de plantilla utilizada para todos los archivos que coinciden es:
Cualquier opción pasada al comando startapp (entre las opciones admitidas por el comando)
app_name – el nombre de la aplicación tal como se le pasa al comando
app_directory – el camino completo del nuevo directorio de la aplicación
camel_case_app_name – el nombre de la aplicación en formato camel case
docs_version – la versión de la documentación: 'dev' o '1.x'
django_version – la versión de Django, p. ej. ` “2.0.3” `
Advertencia
When los archivos de plantilla del app se renderizan con el motor de plantillas Django (por defecto todos los archivos *.py), Django también reemplazará todas las variables de plantilla sueltas contenidas. Por ejemplo, si uno de los archivos Python contiene una docstring que explica una característica particular relacionada con la renderización de plantillas, podría resultar en un ejemplo incorrecto.
Para trabajar alrededor de este problema, puedes utilizar el templatetag etiqueta de plantilla para «escapar» las diferentes partes del sintaxis de plantilla.
Además, para permitir que los archivos de plantilla Python contengan sintaxis de lenguaje de plantillas Django mientras también se previene a los sistemas de empaquetado de intentar compilar bytes inválidos *.py archivos, los archivos de plantilla que terminan con .py-tpl se renombrarán a .py.
Advertencia
Los contenidos de las plantillas personalizadas (o del proyecto) deben auditarse siempre antes de su uso: tales plantillas definen código que se convertirá en parte de tu proyecto, y esto significa que tal código será confiado tanto como cualquier app que instales o el código que escribas tú mismo. Además, incluso la renderización de las plantillas es, efectivamente, ejecutar código que fue proporcionado como entrada al comando de gestión. El lenguaje de plantillas Django puede proporcionar acceso amplio a sistema, así que asegúrate de que cualquier plantilla personalizada que uses sea digna de tu confianza.
startproject¶Crea la estructura de directorios del proyecto Django para el nombre de proyecto dado en el directorio actual o la dirección destino dada.
Por defecto, el nuevo directorio contiene manage.py y un paquete de proyecto (conteniendo un settings.py y otros archivos).
Si solo se da el nombre del proyecto, tanto el directorio del proyecto como el paquete de proyecto se llamarán <projectname> y el directorio del proyecto se creará en el directorio de trabajo actual.
Si la dirección destino opcional se proporciona, Django utilizará ese directorio existente como directorio del proyecto y creará manage.py y el paquete de proyecto dentro de él. Utiliza “.” para denotar el directorio de trabajo actual.
Ejemplo:
django-admin startproject myproject /Users/jezdez/Code/myproject_repo
Especifica un directorio, ruta de archivo o URL de una plantilla de proyecto personalizada. Consulta la documentación de startapp --template para ejemplos y uso. Las mismas consideraciones de seguridad descritas para las plantillas startapp se aplican aquí: plantillas maliciosas o construidas con mala intención pueden introducir debilidades o consumir recursos excesivos, y las plantillas deben inspeccionarse cuidadosamente antes de su uso.
Specifies which file extensions in the proyecto plantilla deben ser renderizados con el motor de plantillas. Por defecto, son py.
Specified que archivos en la plantilla del proyecto (además de aquellos que coinciden con --extension) deben ser renderizados con el motor de plantillas. Por defecto, es una lista vacía.
Specifies qué directorios en la plantilla del proyecto deben excluirse, además de .git y __pycache__. Si no se proporciona esta opción, los directorios llamados __pycache__ o que comienzan con . serán excluidos.
El contexto de plantilla utilizado es:
Cualquier opción pasada al comando startproject (entre las opciones admitidas por el comando)
project_name – el nombre del proyecto tal como se pasa al comando
project_directory – la ruta completa del proyecto recién creado
secret_key – una clave aleatoria para la configuración SECRET_KEY
docs_version – la versión de la documentación: 'dev' o '1.x'
django_version – la versión de Django, p. ej. ` “2.0.3” `
Por favor, también consulte el advertencia de renderizado y advertencia de código confiable como se menciona en startapp.
test¶Ejecuta pruebas para todas las aplicaciones instaladas. Consulta la sección Pruebas en Django para obtener más información.
Detiene la ejecución de pruebas y reporta el fallo inmediatamente después de que una prueba falla.
Controla la clase del ejecutor de pruebas utilizada para ejecutar las pruebas. Este valor supera el valor proporcionado por la configuración TEST_RUNNER.
Suprime todas las solicitudes de usuario. Una solicitud típica es una advertencia sobre la eliminación de una base de datos de prueba existente.
El comando test recibe opciones en nombre del ejecutor de pruebas especificado: --testrunner. Estas son las opciones del ejecutor de pruebas por defecto: DiscoverRunner.
Conserva la base de datos de prueba entre ejecuciones de pruebas. Esto tiene el beneficio de saltarse tanto la creación como la eliminación de acciones que pueden disminuir significativamente el tiempo para ejecutar las pruebas, especialmente aquellas en un conjunto de pruebas grande. Si la base de datos de prueba no existe, se creará en la primera ejecución y luego se conservará para cada ejecución subsiguiente. A menos que la configuración de prueba MIGRATE sea False, también se aplicarán las migraciones no aplicadas a la base de datos de prueba antes de ejecutar el conjunto de pruebas.
Aleatoriza el orden de las pruebas antes de ejecutarlas. Esto puede ayudar a detectar pruebas que no están correctamente aisladas. El orden de las pruebas generado por esta opción es una función determinista del semilla entera proporcionada. Cuando no se pasa ninguna semilla, se elige una semilla al azar y se imprime en la consola. Para repetir un orden particular de pruebas, pasa una semilla. Los ordenamientos aleatorizados también tienen una propiedad de consistencia especial útil cuando se están estrechando problemas de aislamiento. Es decir, para una semilla dada y al ejecutar un subconjunto de pruebas, el nuevo orden será la reordenación original restringida al conjunto más pequeño. De manera similar, cuando se agregan pruebas mientras se mantiene la misma semilla, el orden de las pruebas originales será el mismo en el nuevo orden.
Los ordenamientos aleatorizados también tienen una propiedad de consistencia especial útil cuando se están estrechando problemas de aislamiento. Es decir, para una semilla dada y al ejecutar un subconjunto de pruebas, el nuevo orden será la reordenación original restringida al conjunto más pequeño. De manera similar, cuando se agregan pruebas mientras se mantiene la misma semilla, el orden de las pruebas originales será el mismo en el nuevo orden.
Ordena los casos de prueba en el orden de ejecución opuesto. Esto puede ayudar a depurar los efectos laterales de las pruebas que no están correctamente aisladas. Grupos por clase de caso de prueba se preservan cuando se utiliza esta opción. Esta opción se puede utilizar conjuntamente con --shuffle para revertir el orden para una semilla particular.
Sets the DEBUG setting to True prior a la ejecución de pruebas. Esto puede ayudar a depurar fallos en las pruebas.
Habilita el registro de SQL <django-db-logger> para pruebas fallidas. Si --verbosity es 2, entonces las consultas en pruebas que pasan también se muestran.
Ejecuta pruebas en procesos paralelos separados. Dado que los procesadores modernos tienen múltiples núcleos, esto permite ejecutar pruebas significativamente más rápido.
Usar --parallel sin un valor, o con el valor auto, ejecuta un proceso de prueba por núcleo según multiprocessing.cpu_count(). Puedes sobreescribir esto pasando el número deseado de procesos, por ejemplo --parallel 4, o estableciendo la variable de entorno DJANGO_TEST_PROCESSES.
Django distribuye casos de prueba — clases que heredan de unittest.TestCase — a subprocesses. Si hay menos clases de casos de prueba que procesos configurados, Django reducirá el número de procesos según.
Cada proceso tiene su propia base de datos. Debes asegurarte de que diferentes clases de casos de prueba no acceden a los mismos recursos. Por ejemplo, las clases de casos de prueba que tocan el sistema de archivos deben crear un directorio temporal para su uso propio.
Nota
Si tienes clases de casos de prueba que no pueden ejecutarse en paralelo, puedes usar SerializeMixin para ejecutarlas secuencialmente. Consulta <topics-testing-enforce-run-sequentially>.
Esta opción requiere el paquete de terceros tblib para mostrar las pila de llamadas correctamente:
$ python -m pip install tblib
Esta característica no está disponible en Windows. No funciona con el backend de base de datos Oracle tampoco.
Si deseas usar pdb mientras depuras pruebas, debes deshabilitar la ejecución paralela (--parallel=1). Verás algo como bdb.BdbQuit si no lo haces.
Advertencia
When la paralelización de pruebas está habilitada y una prueba falla, Django puede ser incapaz de mostrar el seguimiento del error. Esto puede hacer que depurar sea difícil. Si encuentras este problema, ejecuta la prueba afectada sin paralelización para ver el seguimiento del error de la falla.
Esto es una limitación conocida. Surge de la necesidad de serializar objetos con el fin de intercambiarlos entre procesos. Consulta What can be pickled and unpickled? para obtener más detalles.
Ejecuta solo las pruebas marcadas con los especificados. Puede especificarse varias veces y combinarse con test --exclude-tag.
Las pruebas que fallan al cargar siempre se consideran coincidentes.
Excluye las pruebas marcadas con los especificados. Puede especificarse varias veces y combinarse con test --tag.
Ejecuta métodos y clases de prueba que coincidan con patrones de nombre de prueba, de la misma manera que unittest's -k option. Puede especificarse varias veces.
Despliega un depurador pdb en cada error o falla de prueba. Si lo tienes instalado, se utiliza ipdb en su lugar.
Descarta la salida (stdout y stderr) para las pruebas que pasan, de la misma manera que unittest's --buffer option.
Django llama automáticamente a faulthandler.enable() cuando se inician las pruebas, lo que permite imprimir un seguimiento si el intérprete se cae. Pasa --no-faulthandler para deshabilitar este comportamiento.
Imprime los tiempos de ejecución, incluyendo la configuración de la base de datos y el tiempo total de ejecución.
Muestra los N casos de prueba más lentos (N=0 para todos).
Python 3.12 y posterior
Esta característica solo está disponible para Python 3.12 y posteriores.
testserver¶Ejecuta un servidor de desarrollo Django (como en runserver) utilizando datos del archivo de pruebas proporcionado(s).
Por ejemplo, esta orden:
django-admin testserver mydata.json
…realizaría los siguientes pasos:
Crea una base de datos de prueba, tal como se describe en la-base-de-datos-de-prueba.
Población la base de datos de prueba con datos del archivo de pruebas proporcionado(s). (Para más información sobre archivos de pruebas, consulte la documentación para loaddata arriba).
Ejecuta el servidor de desarrollo Django (como en runserver), apuntando a esta base de datos de prueba recién creada en lugar de tu base de datos de producción.
Este es el texto traducido:
Cuando estás escribiendo pruebas unitarias (pruebas unitarias ) sobre cómo tus vistas actúan con cierta data fija, puedes utilizar testserver para interactuar con las vistas en un navegador web de manera manual.
Supongamos que estás desarrollando tu aplicación Django y tienes una copia «prístina» de una base de datos a la que te gustaría interactuar. Puedes dumpar tu base de datos a un fixture (utilizando el comando dumpdata, explicado anteriormente), luego puedes utilizar testserver para ejecutar tu aplicación web con esa data. Con esta disposición, tienes la flexibilidad de estropear tus datos de cualquier manera, sabiendo que los cambios en tus datos solo se están haciendo a una base de datos de prueba.
Ten en cuenta que este servidor no detecta automáticamente cambios en tu código fuente Python (como runserver lo hace). Sin embargo, sí detecta cambios en plantillas.
Especifica un puerto diferente o dirección IP y puerto desde el valor por defecto de 127.0.0.1:8000. Este valor sigue exactamente el mismo formato y sirve exactamente la misma función que el argumento del comando runserver.
Ejemplos:
Para ejecutar el servidor de pruebas en el puerto 7000 con fixture1 y fixture2:
django-admin testserver --addrport 7000 fixture1 fixture2
django-admin testserver fixture1 fixture2 --addrport 7000
(Los declaraciones anteriores son equivalentes. Incluimos ambas para demostrar que no importa si las opciones vienen antes o después de los argumentos de la data fija.)
Para ejecutar en 1.2.3.4:7000 con una data fija test:
django-admin testserver --addrport 1.2.3.4:7000 test
Suprime todas las solicitudes de usuario. Una solicitud típica es una advertencia sobre la eliminación de una base de datos de prueba existente.
Algunos comandos solo están disponibles cuando la aplicación django.contrib que implementa los ha sido habilitada. Esta sección describe los agrupados por su aplicación.
changepassword¶Este comando solo está disponible si se ha instalado el sistema de autenticación de Django (sistema de autenticación (django.contrib.auth)).
Permite cambiar la contraseña de un usuario. Te pide que ingresas una nueva contraseña dos veces para el usuario dado. Si las entradas son idénticas, esta se convierte inmediatamente en la nueva contraseña. Si no proporcionas un usuario, el comando intentará cambiar la contraseña del usuario cuyo nombre de usuario coincide con el usuario actual.
Specifica la base de datos a consultar para el usuario. Por defecto es default.
Ejemplo de uso:
django-admin changepassword ringo
createsuperuser¶Este comando solo está disponible si se ha instalado el sistema de autenticación de Django (sistema de autenticación (django.contrib.auth)).
Crea una cuenta de superusuario (un usuario que tiene todos los permisos). Esto es útil si necesitas crear una cuenta de superusuario inicial o si necesitas generar cuentas de superusuario de forma programática para tus sitios web.
Cuando se ejecuta interactivamente, este comando te pedirá la contraseña para la nueva cuenta de superusuario. Cuando se ejecuta no interactivamente, puedes proporcionar una contraseña estableciendo la variable de entorno DJANGO_SUPERUSER_PASSWORD. De lo contrario, no se establecerá ninguna contraseña y la cuenta de superusuario no podrá iniciar sesión hasta que se haya establecido manualmente.
En modo no interactivo, los campos USERNAME_FIELD (USERNAME_FIELD) y los campos requeridos (listados en REQUIRED_FIELDS) recaen en las variables de entorno DJANGO_SUPERUSER_<uppercase_field_name>, a menos que se sobreescriban mediante un argumento de línea de comandos. Por ejemplo, para proporcionar el campo email, puedes usar la variable de entorno DJANGO_SUPERUSER_EMAIL.
Suprime todas las preguntas del usuario. Si una pregunta suprimida no puede resolverse automáticamente, el comando saldrá con código de error 1.
El nombre de usuario y la dirección de correo electrónico para la nueva cuenta se pueden proporcionar utilizando los argumentos --username y --email en la línea de comandos. Si ninguno de ellos se proporciona, createsuperuser te pedirá que lo ingreses cuando se ejecuta interactivamente.
Specifies the base de datos en la que se guardará el objeto superusuario.
Puedes sobreescribir la clase de comando de administración y reemplazar get_input_data() si deseas personalizar la entrada y validación de los datos. Consulta el código fuente para obtener detalles sobre la implementación existente y los parámetros del método. Por ejemplo, podría ser útil si tienes un ForeignKey en REQUIRED_FIELDS y quieres permitir crear una instancia en lugar de ingresar la clave primaria de una instancia existente.
django.contrib.contenttypes¶remove_stale_contenttypes¶Este comando solo está disponible si se ha instalado el paquete contenttypes (django.contrib.contenttypes) de Django.
Elimina los tipos de contenido caducados (de modelos eliminados) en tu base de datos. También se eliminarán cualquier objeto que dependa de los tipos de contenido caducados. Se mostrará una lista de objetos eliminados antes de confirmar que es seguro proceder con la eliminación.
Specifica la base de datos a utilizar. Por defecto, es default.
Elimina los tipos de contenido caducados, incluyendo los de aplicaciones previamente instaladas que han sido eliminadas de INSTALLED_APPS. Por defecto es False.
django.contrib.gis¶Este comando solo está disponible si se ha instalado el paquete GeoDjango (django.contrib.gis).
Por favor, aquí tienes las traducciones de los textos originales:
django.contrib.sessions¶clearsessions¶Puedes ejecutarlo como un trabajo cron o directamente para eliminar las sesiones expiradas.
django.contrib.staticfiles¶collectstatic¶Este comando solo está disponible si se ha instalado la aplicación de archivos estáticos (django.contrib.staticfiles).
Revisa su descripción en la documentación de los archivos estáticos (<ref/contrib/staticfiles>).
findstatic¶Este comando solo está disponible si se ha instalado la aplicación de archivos estáticos (django.contrib.staticfiles).
Revisa su descripción en la documentación de los archivos estáticos (<ref/contrib/staticfiles>).
Aunque algunos comandos pueden permitir opciones personalizadas, cada comando permite las siguientes opciones por defecto:
Adds el camino de sistema de archivos dado al módulo sys.path atributo de Python. Si no se proporciona esto, django-admin utilizará la variable de entorno PYTHONPATH.
Esta opción es innecesaria en manage.py, porque se encarga usted mismo de establecer el camino de Python.
Ejemplo de uso:
django-admin migrate --pythonpath='/home/djangoprojects/myproject'
Specifica el módulo de configuración a usar. El módulo de configuración debe estar en sintaxis de paquete de Python, por ejemplo mysite.settings. Si no se proporciona esto, django-admin utilizará la variable de entorno DJANGO_SETTINGS_MODULE.
Esta opción es innecesaria en manage.py, porque utiliza settings.py del proyecto actual por defecto.
Ejemplo de uso:
django-admin migrate --settings=mysite.settings
Muestra un seguimiento completo de pila cuando se levanta una excepción CommandError. Por defecto, django-admin mostrará un mensaje de error cuando ocurre un CommandError y un seguimiento de pila completo para cualquier otra excepción.
Esta opción es ignorada por runserver.
Ejemplo de uso:
django-admin migrate --traceback
Specifica la cantidad de información de notificación y depuración que una orden debe imprimir en el consola.
0 significa sin salida.
1 significa salida normal (por defecto).
2 significa salida detallada.
3 significa muy verbose output.
Esta opción es ignorada por runserver.
Ejemplo de uso:
django-admin migrate --verbosity 2
Deshabilita la salida de comandos coloreada. Algunos comandos formatean su salida para que sea coloreada. Por ejemplo, los errores se imprimirán en la consola en rojo y las sentencias SQL serán resaltadas sintácticamente.
Ejemplo de uso:
django-admin runserver --no-color
Forza la colorización de la salida del comando si no lo haría de lo contrario, como se discute en Coloración sintáctica. Por ejemplo, puedes querer enviar la salida coloreada a otro comando mediante un tubería.
Saltar la ejecución de comprobaciones del sistema antes de ejecutar el comando. Esta opción solo está disponible si la atributo de comando requires_system_checks no es una lista o tupla vacías.
Ejemplo de uso:
django-admin migrate --skip-checks
Los comandos django-admin / manage.py utilizarán una salida coloreada bonita si tu terminal admite la salida ANSI coloreada. No utilizará los códigos de color si estás enviando la salida del comando a otro programa, a menos que se utilice la opción --force-color.
En Windows 10, la aplicación Windows Terminal , VS Code, y PowerShell (donde el procesamiento de terminal virtual está habilitado) permiten la salida coloreada y están soportadas por defecto.
Bajo Windows, el legado cmd.exe consola nativa no admite secuencias de escape ANSI, por lo que por defecto no hay salida coloreada. En este caso se necesitan dos bibliotecas terceras:
Instala colorama, un paquete de Python que traduce códigos de colores ANSI en llamadas a la API de Windows. Los comandos de Django detectarán su presencia y aprovecharán sus servicios para colorear el output tal como se hace en plataformas basadas en Unix. colorama puede ser instalado mediante pip:
...\> py -m pip install "colorama >= 0.4.6"
Instala ANSICON, una herramienta de terceros que permite a cmd.exe procesar códigos de colores ANSI. Los comandos de Django detectarán su presencia y aprovecharán sus servicios para colorear el output tal como se hace en plataformas basadas en Unix.
Otros entornos de terminal modernos en Windows, que admiten colores de terminal pero no son automáticamente detectados como admitidos por Django, pueden «falsificar» la instalación de ANSICON estableciendo la variable de entorno correspondiente, ANSICON="on".
Los colores utilizados para resaltar sintaxis se pueden personalizar. Django viene con tres paletas de colores:
dark, adecuado para terminales que muestran texto blanco sobre fondo negro. Esta es la paleta por defecto.
light, adecuado para terminales que muestran texto negro sobre fondo blanco.
nocolor, que deshabilita la resaltación de sintaxis.
Puedes seleccionar una paleta estableciendo una variable de entorno DJANGO_COLORS para especificar la paleta que deseas utilizar. Por ejemplo, para especificar la paleta light bajo un shell BASH de Unix o OS/X, deberías ejecutar lo siguiente en una ventana de comando:
export DJANGO_COLORS="light"
También puedes personalizar los colores utilizados. Django especifica un número de roles en los que se utiliza el color:
error - Un error importante.
notice - Un error menor.
success - Éxito.
warning - Una advertencia.
sql_field - El nombre de un campo del modelo en SQL.
sql_coltype - El tipo de un campo del modelo en SQL.
sql_keyword - Una palabra clave SQL.
sql_table - El nombre de un modelo en SQL.
http_info - Una respuesta informativa HTTP 1XX del servidor.
http_success - Una respuesta exitosa HTTP 2XX del servidor.
http_not_modified - Una respuesta del servidor HTTP 304 Not Modified.
http_redirect - Una respuesta del servidor HTTP de redirección 3XX, excepto la 304.
http_not_found - Una respuesta del servidor HTTP 404 No Encontrado.
http_bad_request - Una respuesta del servidor HTTP de solicitud malformada 4XX, excepto la 404.
http_server_error - Una respuesta del servidor HTTP de error del servidor 5XX.
migrate_heading - Un encabezado en un comando de gestión de migraciones.
migrate_label - El nombre de una migración.
Cada uno de estos roles puede asignarse un color de fondo y de frente específico, desde la siguiente lista:
black
red
verde
amarillo
azul
magenta
cian
blanco
Cada uno de estos colores puede modificarse luego utilizando las siguientes opciones de visualización:
negrita
subrayado
parpadeante
inverso
ocultar
Una especificación de color sigue uno de los siguientes patrones:
papel=fg
papel=fg/fondo
papel=fg,opción,opción
papel=fg/fondo,opción,opción
donde papel es el nombre de un papel de color válido, fg es el color del primer plano, bg es el color del fondo y cada opción es una de las opciones que modifican el color. Se pueden especificar múltiples especificaciones de color separadas por un punto y coma. Por ejemplo:
export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
especificaría que los errores se muestren utilizando amarillo parpadeante sobre azul, y las notificaciones se muestren con magenta. Todos los demás papeles de color se dejarían sin colorear.
Los colores también pueden especificarse extendiendo una paleta base. Si pones el nombre de una paleta en una especificación de color, se cargarán todos los colores implicados por esa paleta. Por lo tanto:
export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
would especificar el uso de todos los colores en la paleta de colores de luz, excepto para los colores de errores y advertencias que serían sobrescritos tal como se especifica.
Si utilizas la shell de Bash, considera instalar el script de completado de Bash de Django, que vive en extras/django_bash_completion en la distribución de fuentes de Django. Permite la completación de tabulador de comandos django-admin y manage.py, por lo que puedes, por ejemplo…
Escribe django-admin.
Presiona [TAB] para ver todas las opciones disponibles.
Escribe sql, luego [TAB], para ver todas las opciones cuyos nombres comienzan con sql.
Consulte Cómo crear comandos personalizados de django-admin para saber cómo agregar acciones personalizadas.
Los archivos Python creados por startproject, startapp, optimizemigration, makemigrations, y squashmigrations se formatean utilizando el comando black si está presente en tu PATH.
Si tienes black instalado globalmente, pero no deseas que se utilice para el proyecto actual, puedes establecer explícitamente el PATH:
PATH=path/to/venv/bin django-admin makemigrations
Para comandos que utilizan stdout puedes redirigir la salida a black si es necesario:
django-admin inspectdb | black -
Para llamar un comando de gestión desde el código utiliza call_command().
nombreel nombre del comando a llamar o un objeto de comando. Pasar el nombre es preferible a menos que el objeto sea necesario para la prueba.
*argsuna lista de argumentos aceptados por el comando. Los argumentos se pasan al parser de argumentos, por lo que puedes utilizar el mismo estilo que en la línea de comandos. Por ejemplo, call_command('flush', '--verbosity=0').
**optionsopciones nombradas aceptadas en la línea de comandos. Las opciones se pasan al comando sin desencadenar el parser de argumentos, lo que significa que debes pasar el tipo correcto. Por ejemplo, call_command('flush', verbosity=0) (cero debe ser un entero y no una cadena).
Ejemplos:
from django.core import management
from django.core.management.commands import loaddata
management.call_command("flush", verbosity=0, interactive=False)
management.call_command("loaddata", "test_data", verbosity=0)
management.call_command(loaddata.Command(), "test_data", verbosity=0)
Ten en cuenta que las opciones de comandos que no aceptan argumentos se pasan como palabras clave con True o False, como puedes ver con la opción interactive anterior.
Los argumentos nombrados se pueden pasar utilizando cualquiera de los siguientes formatos:
# Similar to the command line
management.call_command("dumpdata", "--natural-foreign")
# Named argument similar to the command line minus the initial dashes and
# with internal dashes replaced by underscores
management.call_command("dumpdata", natural_foreign=True)
# `use_natural_foreign_keys` is the option destination variable
management.call_command("dumpdata", use_natural_foreign_keys=True)
Algunas opciones de comandos tienen nombres diferentes cuando se utilizan con call_command() en lugar de django-admin o manage.py. Por ejemplo, django-admin createsuperuser –no-input se traduce a call_command(“createsuperuser”, interactive=False). Para encontrar el nombre del argumento clave para usar con call_command(), revisa el código fuente del comando en busca del argumento dest pasado a parser.add_argument().
Las opciones de comandos que aceptan múltiples opciones se pasan una lista:
management.call_command("dumpdata", exclude=["contenttypes", "auth"])
El valor de retorno de la función call_command() es el mismo que el valor de retorno del método handle() del comando.
Ten en cuenta que puedes redirigir los streams de salida y error como todos los comandos admiten las opciones stdout y stderr. Por ejemplo, podrías escribir:
with open("/path/to/command_output", "w") as f:
management.call_command("dumpdata", stdout=f)
may 31, 2026