django-admin.py et manage.py

django-admin.py est l’utilitaire en ligne de commande de Django pour les tâches administratives. Ce document décrit tout ce qu’il peut faire.

De plus, manage.py est créé automatiquement dans chaque projet Django.``manage.py`` est un adaptateur léger autour de django-admin.py et se charge de deux choses à votre place avant de déléguer la suite à django-admin.py:

  • Il place le paquet de votre projet dans le chemin sys.path.

  • Il définit la variable d’environnement DJANGO_SETTINGS_MODULE afin qu’elle pointe vers le fichier settings.py de votre projet.

Le script django-admin.py devrait se trouver dans votre chemin système si vous avez installé Django par son utilitaire setup.py. S’il ne se trouve pas dans votre chemin, vous pouvez le trouver dans le répertoire site-packages/django/bin de votre installation Python. Il est alors conseillé de créer un lien symbolique quelque part dans votre chemin, comme par exemple dans /usr/local/bin.

Les utilisateurs de Windows, qui n’ont pas de liens symboliques à leur disposition, peuvent copier django-admin.py dans un emplacement du chemin existant ou modifier la variable PATH (sous Panneau de configuration - Système - Avancé - Environnement…) pour qu’elle contienne l’emplacement d’installation.

Généralement, en travaillant dans un seul projet Django, il est plus simple d’utiliser manage.py plutôt que django-admin.py. Si vous devez basculer entre différents fichiers de réglages Django, utilisez la variable DJANGO_SETTINGS_MODULE ou l’option de ligne de commande --settings de la commande django-admin.py.

Les exemples en ligne de commande tout au long de ce document utilisent django-admin.py par cohérence, mais tous les exemples pourraient tout aussi bien utiliser manage.py.

Utilisation

django-admin.py <command> [options]
manage.py <command> [options]

command doit correspondre à l’une des commandes mentionnées dans ce document. options, qui est facultatif, doit correspondre à zéro ou plusieurs options disponibles pour la commande concernée.

Obtention d’aide

django-admin.py help

Lancez django-admin.py help pour afficher des informations d’utilisation et une liste des commandes fournies par chaque application.

Lancez django-admin.py help --commands pour afficher une liste des commandes disponibles.

Lancez django-admin.py help <command> pour afficher une description de la commande concernée et une liste de ses options disponibles.

Noms d’applications

Plusieurs commandes acceptent une liste de « noms d’applications ». Un nom d’application est le nom de base du paquet contenant les modèles. Par exemple, si votre réglage INSTALLED_APPS contient la chaîne 'mysite.blog', le nom d’application est blog.

Détermination de la version

django-admin.py version

Lancez django-admin.py version pour afficher la version actuelle de Django.

L’affichage correspond au schéma décrit dans la PEP 386:

1.4.dev17026
1.4a1
1.4

Affichage du contenu de débogage

Utilisez --verbosity pour indiquer la quantité d’informations indicatives et de débogage que django-admin.py doit afficher dans la console. Pour plus de détails, consultez la documentation de l’option --verbosity.

Commandes disponibles

check

django-admin.py check
New in Django 1.6.

Effectue une série de vérifications pour contrôler qu’une configuration donnée (réglages/code d’application) est compatible avec la version actuelle de Django.

Lorsque cette commande trouve des éléments incompatibles ou qui demandent que l’utilisateur soit averti, elle affiche une série d’avertissements.

cleanup

django-admin.py cleanup

Peut être exécutée comme une commande « cron » ou directement pour nettoyer d’anciennes données de la base de données (seulement les sessions qui ont expiré pour l’instant).

Changed in Django 1.5:

cleanup est obsolète. Utilisez clearsessions à la place.

compilemessages

django-admin.py compilemessages

Compile les fichiers .po créés par makemessages en fichiers .mo utilisables par l’outil intégré gettext. Voir Internationalisation et régionalisation.

Utilisez l’option --locale (ou sa version abrégée -l) pour indiquer les langues à traiter. Sans autre information, toutes les langues sont traitées.

Exemple d’utilisation :

django-admin.py compilemessages --locale=pt_BR
django-admin.py compilemessages --locale=pt_BR --locale=fr
django-admin.py compilemessages -l pt_BR
django-admin.py compilemessages -l pt_BR -l fr
Changed in Django 1.6:

La possibilité d’indiquer plusieurs langues a été ajoutée.

createcachetable

django-admin.py createcachetable

Crée une table de cache nommée tablename à l’usage du moteur de cache en base de données. Voir L’infrastructure de cache dans Django pour plus d’informations.

L’option --database peut être utilisée pour indiquer la base de données dans laquelle la table de cache sera créée.

dbshell

django-admin.py dbshell

Lance le client en ligne de commande correspondant au moteur de base de données défini dans le réglage ENGINE, en respectant les paramètres de connexion définis dans les réglages USER, PASSWORD, etc.

  • Pour PostgreSQL, cette commande lance le client en ligne de commande psql.

  • Pour MySQL, cette commande lance le client en ligne de commande mysql.

  • Pour SQLite, cette commande lance le client en ligne de commande sqlite3.

Cette commande compte sur le fait que les programmes sont accessibles dans le chemin d’exécution afin qu’en appelant simplement leur nom (psql, mysql, sqlite3), le bon programme est lancé. Il n’y a pas d’astuce pour indiquer manuellement le chemin du programme de base de données.

L’option --database peut être utilisée pour indiquer la base de données pour laquelle le shell doit être ouvert.

diffsettings

django-admin.py diffsettings

Affiche les différences entre le fichier de réglages actuel et les réglages par défaut de Django.

Les réglages qui ne figurent pas dans les réglages par défaut sont suivis par "###". Par exemple, les réglages par défaut ne définissent pas ROOT_URLCONF, donc ROOT_URLCONF est suivi par "###" dans l’affichage que produit diffsettings.

L’option --all peut être fournie pour afficher tous les réglages, même s’ils contiennent la valeur par défaut de Django. Ces réglages sont alors préfixés par "###".

New in Django 1.6:

L’option --all a été ajoutée.

dumpdata <nom_app nom_app nom_app.Model ...>

django-admin.py dumpdata

Affiche dans la sortie standard toutes les données de la base de données associée à ou aux applications nommées.

Si aucun nom d’application n’est indiqué, le contenu de toutes les applications installées est affiché.

La sortie de dumpdata peut être utilisée comme source d’entrée pour loaddata.

Notez que dumpdata utilise le gestionnaire par défaut des modèles lors de la sélection des enregistrements à afficher. Si vous avez configuré un gestionnaire personnalisé comme gestionnaire par défaut et qu’il exclut certains des enregistrements existants, vous n’obtiendrez alors pas l’ensemble des objets dans l’affichage.

L’option --all peut être indiquée pour signifier que dumpdata doit utiliser le gestionnaire de base de Django, affichant ainsi des enregistrements qui ne seraient pas visibles ou qui seraient modifiés en raison d’un gestionnaire personnalisé.

--format <fmt>

Par défaut, dumpdata affiche le contenu au format JSON, mais il est possible d’indiquer l’option --format pour faire appel à un autre format. Les formats actuellement pris en charge sont énumérés dans Formats de sérialisation.

--indent <num>

Par défaut, dumpdata affiche toutes les données sur une seule ligne. Ce n’est pas très agréable à lire pour des humains, il est donc possible d’utiliser l’option --indent pour mettre en forme l’affichage selon le nombre d’espaces d’indentation indiqué.

L’option --exclude peut être indiquée pour empêcher des applications ou des modèles (désignés sous la forme nom_app.NomModèle) d’être affichés. Si vous indiquez un nom de modèle à dumpdata, l’affichage produit sera limité à ce modèle plutôt qu’à toute l’application. Il est aussi possible de mélanger des noms d’applications et des noms de modèles.

L’option --database peut être utilisée pour indiquer la base de données à partir de laquelle les données seront produites.

--natural

Utilisez les clés naturelles pour représenter des relations de clé étrangères ou plusieurs-à-plusieurs d’un modèle qui contient des définitions de clé naturelle. Si vous affichez des objets Permission de contrib.auth ou des objets ContentType de contrib.contenttypes, il est recommandé d’utiliser cette option.

New in Django 1.6.
--pks

Par défaut, dumpdata traite toutes les occurrences du modèle, mais il est possible d’utiliser l’option --pks pour indiquer un filtre sous forme d’une liste de clés primaires séparées par des virgules. Cette option n’est valable que lorsque l’exportation concerne un seul modèle.

flush

django-admin.py flush

Remet la base de donnée dans son état juste après l’exécution de syncdb. Cela signifie que toutes les données sont effacées de la base de données, que tout gestionnaire post-synchronisation sera exécuté à nouveau et que les instantanés initial_data sont réinstallés.

L’option --noinput peut être indiquée pour prévenir toute demande interactive à l’utilisateur.

L’option --database peut être utilisée pour indiquer la base de données qu’il s’agit de réinitialiser.

--no-initial-data

New in Django 1.5.

Utilisez --no-initial-data pour éviter de charger les instantanés initial_data.

inspectdb

django-admin.py inspectdb

Introspecte les tables de base de données de la base désignée dans le réglage NAME et affiche un module de modèle Django (un fichier models.py) vers la sortie standard.

Cette commande est utile dans le cas d’une base de données existante que vous aimeriez utilisez avec Django. Le script inspecte la base de données et crée un modèle pour chacune de ses tables.

Comme l’on peut s’y attendre, les modèles créés possèdent un attribut pour chaque champ de table. Notez que inspectdb gère quelques cas particuliers dans sa manière de nommer les champs :

  • Si inspectdb ne peut pas faire correspondre un type de colonne à un type de champ de modèle, il utilise TextField et ajoute le commentaire 'This field type is a guess.' (ce type de champ est approximatif) à côté de la définition du champ dans le modèle généré.

  • Si le nom de colonne de base de données est un mot Python réservé (comme 'pass', 'class' ou 'for'), inspectdb ajoute '_field' au nom d’attribut. Par exemple, si une table possède une colonne``’for’, le modèle généré contiendra un champ  ``'for_field' dont l’attribut db_column sera 'for'. inspectdb ajoute le commentaire Python 'Field renamed because it was a Python reserved word.' (champ renommé car il s’agit d’un mot Python réservé) après le champ.

Cette fonctionnalité doit être comprise comme un raccourci, pas comme une génération de modèle définitive. Après l’exécution de la commande, il est nécessaire de réviser vous-même les modèles générés pour faire les adaptations nécessaires. En particulier, il est généralement utile de réarranger l’ordre des modèles afin que les modèles se référant à d’autres modèles apparaissent dans le bon ordre.

Les clés primaires sont automatiquement détectées pour PostgreSQL, MySQL et SQLite, auquel cas Django génère le paramètre primary_key=True là où c’est nécessaire.

inspectdb fonctionne avec PostgreSQL, MySQL et SQLite. La détection de clés étrangères ne fonctionne qu’avec PostgreSQL et certains types de tables MySQL.

Django doesn’t create database defaults when a default is specified on a model field. Similarly, database defaults aren’t translated to model field defaults or detected in any fashion by inspectdb.

Par défaut, inspectdb crée des modèles non pilotés. C’est-à-dire que la présence de managed = False dans la classe Meta des modèles indique à Django de ne pas piloter la création de la table correspondante, ni sa destruction. Si vous voulez autoriser Django à piloter le cycle de vie des tables, il est nécessaire de modifier l’option managed pour lui donner la valeur True (ou simplement l’enlever, car True est sa valeur par défaut).

L’option --database peut être utilisée pour indiquer la base de données qu’il s’agit d’analyser.

Changed in Django 1.6:

Le comportement par lequel les modèles automatiquement générés sont créés initialement comme non gérés (managed = False) est nouveau dans Django 1.6.

loaddata <instantané instantané ...>

django-admin.py loaddata

Recherche et charge le contenu de l’instantané indiqué dans la base de données.

L’option --database peut être utilisée pour indiquer la base de données dans laquelle les données seront chargées.

--ignorenonexistent
New in Django 1.5.

L’option --ignorenonexistent peut être utilisée pour ignorer les champs qui pourraient avoir été enlevés des modèles depuis que l’instantané a été initialement produit.

Qu’est-ce qu’un « instantané » (fixture en anglais) ?

Un instantané est un ensemble de fichiers contenant du contenu sérialisé de base de données. Chaque instantané possède un nom unique et les fichiers composant l’instantané peuvent être distribués dans plusieurs répertoires et plusieurs applications.

Django recherche les instantanés dans trois emplacements :

  1. Dans le répertoire fixtures de chaque application installée

  2. Dans tout répertoire énuméré dans le réglage FIXTURE_DIRS

  3. Dans le chemin explicitement contenu dans le nom de l’instantané

Django charge tous les instantanés qu’il trouve à ces emplacements et qui correspondent aux noms d’instantanés indiqués.

Si le nom d’instantané possède une extension de fichier, seuls les instantanés de ce type seront chargés. Par exemple :

django-admin.py loaddata mydata.json

ne charge que les instantanés JSON nommés mydata. L’extension d’instantané doit correspondre au nom enregistré d’un sérialiseur (par ex. json ou xml).

Si vous omettez l’extension, Django recherche tous les types d’instantané disponibles pour chaque instantané trouvé. Par exemple :

django-admin.py loaddata mydata

recherche tout instantané ou type d’instantané nommé mydata. Si un répertoire d’instantané contient mydata.json, cet instantané serait chargé comme instantané JSON.

Les noms d’instantanés peuvent contenir une partie « chemin ». Ces répertoires sont alors inclus dans le chemin de recherche. Par exemple :

django-admin.py loaddata foo/bar/mydata.json

recherche <nom_app>/fixtures/foo/bar/mydata.json pour chaque application installée, <nom_rép>/foo/bar/mydata.json pour chaque répertoire dans FIXTURE_DIRS ainsi que le chemin littéral foo/bar/mydata.json.

Lorsque des fichiers d’instantanés sont traités, les données sont enregistrées telles quelles dans la base de données. Les méthodes save() définies dans les modèles ne sont pas appelées et les éventuels signaux pre_save ou post_save sont appelés avec raw=True car l’instance ne contient que les attributs locaux du modèle. Il est par exemple imaginable de désactiver les gestionnaires accédant aux champs liés absents lors du chargement des instantanés, car une exception serait générée dans le cas contraire :

from django.db.models.signals import post_save
from .models import MyModel

def my_handler(**kwargs):
    # disable the handler during fixture loading
    if kwargs['raw']:
        return
    ...

post_save.connect(my_handler, sender=MyModel)

On pourrait aussi écrire un décorateur simple pour encapsuler cette logique :

from functools import wraps

def disable_for_loaddata(signal_handler):
    """
    Decorator that turns off signal handlers when loading fixture data.
    """
    @wraps(signal_handler)
    def wrapper(*args, **kwargs):
        if kwargs['raw']:
            return
        signal_handler(*args, **kwargs)
    return wrapper

@disable_for_loaddata
def my_handler(**kwargs):
    ...

Il faut cependant être conscient que cette logique désactivera les signaux lors de chaque désérialisation des instantanés, pas seulement durant loaddata.

Notez que l’ordre de chargement des fichiers d’instantanés n’est pas déterminé. Cependant, toutes les données d’instantanés sont installées dans une seule transaction, afin que des données d’un instantané puissent référencer des données d’un autre instantané. Si le moteur de base de données prend en charge les contraintes au niveau ligne, ces contraintes sont contrôlées à la fin de la transaction.

La commande dumpdata peut être utilisée pour générer le contenu donné à loaddata.

Instantanés compressés

Les instantanés peuvent être compressés dans les formats zip, gz ou bz2. Par exemple :

django-admin.py loaddata mydata.json

recherche l’un des fichiers mydata.json, mydata.json.zip, mydata.json.gz ou mydata.json.bz2. Le premier fichier contenu dans une archive compressée en zip est utilisé.

Notez que si deux instantanés de même nom mais de type différent sont trouvés (par exemple si mydata.json et mydata.xml.gz sont trouvés dans le même répertoire d’instantanés), l’installation des instantanés est interrompue et toute donnée déjà installée par l’appel à loaddata est retirée de la base de données.

MySQL avec MyISAM et les instantanés

Le moteur de stockage MyISAM de MySQL ne gère ni les transactions, ni les contraintes. Si vous utilisez ce moteur, les données d’instantanés ne sont pas validées et d’éventuelles données déjà chargées en base de données ne sont pas effacées dans le cas où des fichiers d’instantanés conflictuels sont trouvés.

Instantanés spécifiques à certaines bases de données

Si vous vous trouvez dans une configuration avec plusieurs bases de données, il se pourrait que vous vouliez charger certains instantanés dans une base de données mais pas dans l’autre. Dans cette situation, vous pouvez insérer des identifiants de base de données dans les noms des instantanés.

Par exemple, si votre réglage DATABASES contient une base de données « master », nommez l’instantané mesdonnees.master.json ou mesdonnees.master.json.gz et cet instantané ne sera chargé que lorsque vous indiquez que vous souhaitez charger des données dans la base de données master.

makemessages

django-admin.py makemessages

Parcourt l’entier de l’arborescence de code source à partir du répertoire actuel et extrait toutes les chaînes marquées pour la traduction. Elle crée (ou met à jour) un fichier de messages dans le répertoire conf/locale (pour l’arborescence Django) ou locale (pour les projets et applications). Après la mise à jour des fichiers de messages, il est encore nécessaire de les compiler par compilemessages pour qu’ils soient utilisables par l’outil intégré gettext. Voir la documentation d’internationalisation pour plus de détails.

--all

Utilisez l’option --all ou -a pour mettre à jour les fichiers de messages pour toutes les langues disponibles.

Exemple d’utilisation :

django-admin.py makemessages --all
--extension

Utilisez l’option --extension ou -e pour indiquer une liste d’extensions de fichiers à examiner (par défaut : ”.html”, ”.txt”).

Exemple d’utilisation :

django-admin.py makemessages --locale=de --extension xhtml

Séparez plusieurs extensions par des virgules ou utilisez l’extension -e ou –extension à plusieurs reprises :

django-admin.py makemessages --locale=de --extension=html,txt --extension xml

Utilisez l’option --locale (ou sa version abrégée -l) pour indiquer les langues à traiter.

Exemple d’utilisation :

django-admin.py makemessages --locale=pt_BR
django-admin.py makemessages --locale=pt_BR --locale=fr
django-admin.py makemessages -l pt_BR
django-admin.py makemessages -l pt_BR -l fr
Changed in Django 1.6:

La possibilité d’indiquer plusieurs langues a été ajoutée.

--domain

Utilisez l’option --domain ou -d pour modifier le domaine des fichiers de messages. Sont actuellement pris en charge :

  • django pour tous les fichiers *.py, *.html et *.txt (par défaut)

  • djangojs pour les fichiers *.js

Utilisez l’option --symlinks ou -s pour suivre les liens symboliques vers les répertoires lors de la recherche de nouvelles chaînes à traduire.

Exemple d’utilisation :

django-admin.py makemessages --locale=de --symlinks
--ignore

Utilisez l’option --ignore ou -i pour ignorer les fichiers ou répertoires correspondant au motif de type glob donné. L’option peut être indiquée plusieurs fois pour des motifs différents.

Ces motifs sont utilisés par défaut : 'CVS', '.*', '*~'

Exemple d’utilisation :

django-admin.py makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
--no-default-ignore

Utilisez l’option --no-default-ignore pour désactiver les valeurs par défaut de --ignore.

--no-wrap

Utilisez l’option --no-wrap pour désactiver la segmentation des longues lignes de messages sur plusieurs lignes dans les fichiers de langues.

--no-location

Utilisez l’option --no-location pour que le script n’écrive pas de ligne commentaire #: filename:line dans les fichiers de langues. Notez qu’avec cette option, les traducteurs ayant de bonnes notions techniques auront plus de peine à saisir le contexte de chaque message.

--keep-pot
New in Django 1.6.

Utilisez l’option --keep-pot pour empêcher Django de supprimer le fichier .pot temporaire qu’il génère avant de créer le ou les fichiers .po. Cela peut être utile pour déboguer d’éventuelles erreurs empêchant la création des fichiers de langues finaux.

runfcgi [options]

django-admin.py runfcgi

Démarre un ensemble de processus FastCGI à disposition de tout serveur Web prenant en charge le protocole FastCGI. Voir la documentation de déploiement de FastCGI pour plus de détails. Nécessite le module Python FastCGI de flup.

En interne, ceci enveloppe l’objet application WSGI désigné par le réglage WSGI_APPLICATION.

Les options admises par cette commande sont transmises à la bibliothèque FastCGI et n’utilisent pas le préfixe '--' comme le font les autres commandes de gestion de Django.

protocol

protocol=PROTOCOLE

Le protocole à utiliser. PROTOCOLE peut être fcgi, scgi, ajp, etc. (la valeur par défaut est fcgi)

host

host=NOM_HÔTE

Le nom d’hôte qu’il s’agit d’écouter.

port

port=NUMÉRO_PORT

Le numéro de port qu’il s’agit d’écouter.

socket

socket=FICHIER

Le connecteur UNIX qu’il s’agit d’écouter.

method

method=IMPL

Valeurs possibles : prefork ou threaded (valeur par défaut : prefork)

maxrequests

maxrequests=NOMBRE

Nombre de requêtes qu’un processus fils gère avant d’être tué et qu’un autre processus soit généré (0 signifie pas de limite)

maxspare

maxspare=NOMBRE

Nombre maximum de processus/fils d’exécution en attente.

minspare

minspare=NOMBRE

Nombre minimum de processus/fils d’exécution en attente.

maxchildren

maxchildren=NOMBRE

Nombre maximal absolu de processus/fils d’exécution.

daemonize

daemonize=BOOL

Indique s’il faut détacher le processus du terminal.

pidfile

pidfile=FICHIER

Écrire l’identifiant de processus généré dans le fichier FICHIER.

workdir

workdir=RÉPERTOIRE

Se placer dans le répertoire RÉPERTOIRE lors du lancement du service.

debug

debug=BOOL

Définir à « true » pour activer les traces de débogage flup.

outlog

outlog=FICHIER

Écrire la sortie standard stdout vers le fichier FICHIER.

errlog

errlog=FICHIER

Écrire la sortie d’erreur stderr vers le fichier FICHIER.

umask

umask=UMASK

Umask to use when daemonizing. The value is interpreted as an octal number (default value is 0o22).

Exemple d’utilisation :

django-admin.py runfcgi socket=/tmp/fcgi.sock method=prefork daemonize=true \
    pidfile=/var/run/django-fcgi.pid

Lance un serveur FastCGI en mode service et écrit l’identifiant de processus PID généré dans un fichier.

runserver [port ou adresse:port]

django-admin.py runserver

Démarre un serveur Web de développement léger sur la machine locale. Par défaut, le serveur fonctionne sur le port 8000 à l’adresse IP 127.0.0.1. Vous pouvez lui transmettre explicitement une adresse IP et un numéro de port.

Si vous lancez ce script avec un utilisateur ayant des privilèges normaux (ce qui est recommandé), il se peut que vous n’ayez pas les permissions d’utiliser un petit numéro de port. Les petits numéros de port sont réservés au super-utilisateur (root).

Ce serveur utilise l’objet application WSGI désigné par le réglage WSGI_APPLICATION.

N’UTILISEZ PAS CE SERVEUR DANS UN ENVIRONNEMENT DE PRODUCTION. Il n’a pas fait l’objet d’audits de sécurité ni de tests de performance. (Et cela n’est pas prévu de changer. Notre métier est de nous occuper de cadriciel Web, pas de serveur Web, et l’amélioration de ce serveur pour pouvoir gérer un environnement de production dépasse les objectifs de Django).

Le serveur de développement recharge automatiquement le code Python lors de chaque requête si nécessaire. Vous ne devez pas redémarrer le serveur pour que les changements de code soient pris en compte. Cependant, certaines actions comme l’ajout de fichiers ou la compilation de fichiers de traduction ne provoquent pas de redémarrage, il est donc nécessaire de redémarrer manuellement le serveur dans ces cas.

Au démarrage du serveur et lors de chaque modification de code Python durant le fonctionnement du serveur, celui-ci valide tous les modèles installés (voir la commande validate ci-dessous). Si la validation détecte des erreurs, celles-ci sont affichées dans la sortie standard, mais le serveur n’est pas interrompu.

Vous pouvez lancer autant de serveurs que nécessaire, pour autant que ce soit sur des ports séparés. Il suffit d’exécuter plusieurs fois django-admin.py runserver.

Notez que l’adresse IP par défaut, 127.0.0.1, n’est pas accessible à partir d’autres machines du réseau. Pour que le serveur de développement soit visible à partir d’autres machines du réseau, utilisez sa propre adresse IP (par ex. 192.168.2.1) ou 0.0.0.0 ou :: (si IPv6 est activé).

Vous pouvez indiquer une adresse IPv6 entourée par des crochets (par ex. [200a::1]:8000). Cela active automatiquement la prise en charge de IPv6.

Il est aussi possible d’indiquer un nom d’hôte uniquement formé de caractères ASCII.

Si l’application complémentaire staticfiles est activée (c’est le cas par défaut dans les nouveaux projets), la commande runserver est surchargée par sa propre commande runserver.

--noreload

Utilisez l’option --noreload pour désactiver le recours au relanceur automatique. Cela signifie que toute modification de code Python effectuée pendant que le serveur tourne ne sera pas prise en compte si le module Python concerné a déjà été chargé en mémoire.

Exemple d’utilisation :

django-admin.py runserver --noreload
--nothreading

Le serveur de développement gère par défaut plusieurs fils d’exécution (« multithread »). Utilisez l’option --nothreading pour désactiver l’utilisation des fils d’exécution avec le serveur de développement.

--ipv6, -6

Utilisez l’option --ipv6 (or plus courtement -6) pour indiquer à Django d’utiliser IPv6 pour le serveur de développement. L’adresse IP par défaut passe alors de 127.0.0.1 à ::1.

Exemple d’utilisation :

django-admin.py runserver --ipv6

Exemples d’utilisation de différents ports et adresses

Port 8000 sur l’adresse IP 127.0.0.1:

django-admin.py runserver

Port 8000 sur l’adresse IP 1.2.3.4:

django-admin.py runserver 1.2.3.4:8000

Port 7000 sur l’adresse IP 127.0.0.1:

django-admin.py runserver 7000

Port 7000 sur l’adresse IP 1.2.3.4:

django-admin.py runserver 1.2.3.4:7000

Port 8000 sur l’adresse IPv6 ::1:

django-admin.py runserver -6

Port 7000 sur l’adresse IPv6 ::1:

django-admin.py runserver -6 7000

Port 7000 sur l’adresse IPv6 2001:0db8:1234:5678::9:

django-admin.py runserver [2001:0db8:1234:5678::9]:7000

Port 8000 sur l’adresse IPv4 de l’hôte localhost:

django-admin.py runserver localhost:8000

Port 8000 sur l’adresse IPv6 de l’hôte localhost:

django-admin.py runserver -6 localhost:8000

Service des fichiers statiques avec le serveur de développement

Par défaut, le serveur de développement ne s’occupe pas de servir les fichiers statiques de votre site (comme les fichiers CSS, les images, ce qui se trouve dans MEDIA_URL, etc.). Si vous souhaitez configurer Django afin qu’il serve les contenus statiques, consultez Gestion des fichiers statiques (CSS, images).

shell

django-admin.py shell

Lance l’interpréteur interactif Python.

Django utilise IPython ou bpython s’ils sont installés. Si vous avez l’un de ces shells enrichis installé mais que vous aimeriez lancer l’interpréteur « brut » de Python, utilisez l’option --plain, comme ceci :

django-admin.py shell --plain

Si vous aimeriez désigner IPython ou bpython comme interpréteur et que les deux sont installés, vous pouvez indiquer l’interpréteur de façon explicite par l’option -i ou --interface comme ceci :

IPython :

django-admin.py shell -i ipython
django-admin.py shell --interface ipython

bpython :

django-admin.py shell -i bpython
django-admin.py shell --interface bpython

Lorsque l’interpréteur interactif Python « brut » démarre (que ce soit en raison de l’option --plain ou parce qu’aucun autre interpréteur n’est disponible), il lit le script indiqué dans la variable d’environnement PYTHONSTARTUP ainsi que le script ~/.pythonrc.py. Si ce comportement ne vous convient pas, vous pouvez utiliser l’option --no-startup, par exemple :

django-admin.py shell --plain --no-startup
New in Django 1.5:

L’option --interface a été ajoutée dans Django 1.5.

New in Django 1.6:

L’option --no-startup a été ajoutée dans Django 1.6.

sql <nom_app nom_app ...>

django-admin.py sql

Affiche les instructions SQL CREATE TABLE relatives aux noms d’application donnés.

L’option --database peut être utilisée pour indiquer la base de données pour laquelle les instructions SQL doivent être affichées.

sqlall <nom_app nom_app ...>

django-admin.py sqlall

Affiche les instructions SQL CREATE TABLE et de données initiales relatives aux noms d’application donnés.

Référez-vous à la description de sqlcustom pour plus d’explications sur la manière de fournir des données initiales.

L’option --database peut être utilisée pour indiquer la base de données pour laquelle les instructions SQL doivent être affichées.

sqlclear <nom_app nom_app ...>

django-admin.py sqlclear

Affiche les instructions SQL DROP TABLE relatives aux noms d’application donnés.

L’option --database peut être utilisée pour indiquer la base de données pour laquelle les instructions SQL doivent être affichées.

sqlcustom <nom_app nom_app ...>

django-admin.py sqlcustom

Affiche les instructions SQL personnalisées relatives aux noms d’application donnés.

Pour chaque modèle de chaque application indiquée, cette commande cherche le fichier <nom_app>/sql/<nom_modèle>.sql, où <nom_app> est le nom d’application indiqué et <nom_modèle> est le nom du modèle en minuscules. Par exemple, si vous avez une application news contenant un modèle Story, sqlcustom essaie de lire le fichier news/sql/story.sql et ajoute son contenu à l’affichage de cette commande.

Chacun des fichiers SQL, le cas échéant, est supposé contenir du code SQL valable. Les fichiers SQL sont directement redirigés vers la commande de base de données après que toutes les instructions de création de table pour les modèles ont été exécutées. Utilisez ce point d’entrée SQL pour effectuer d’éventuelles modifications de table ou pour insérer des fonctions SQL dans la base de données.

Notez que l’ordre dans lequel les différents fichiers SQL sont traités n’est pas défini.

L’option --database peut être utilisée pour indiquer la base de données pour laquelle les instructions SQL doivent être affichées.

sqldropindexes <nom_app nom_app ...>

django-admin.py sqldropindexes
New in Django 1.6.

Affiche les instructions SQL DROP INDEX relatives aux noms d’application donnés.

L’option --database peut être utilisée pour indiquer la base de données pour laquelle les instructions SQL doivent être affichées.

sqlflush

django-admin.py sqlflush

Affiche les commandes SQL qui seraient générées si la commande flush était exécutée.

L’option --database peut être utilisée pour indiquer la base de données pour laquelle les instructions SQL doivent être affichées.

sqlindexes <nom_app nom_app ...>

django-admin.py sqlindexes

Affiche les instructions SQL CREATE INDEX relatives aux noms d’application donnés.

L’option --database peut être utilisée pour indiquer la base de données pour laquelle les instructions SQL doivent être affichées.

sqlsequencereset <nom_app nom_app ...>

django-admin.py sqlsequencereset

Affiche les instructions SQL de réinitialisation des séquences relatives aux noms d’application donnés.

Les séquences sont des index utilisés par certains moteurs de base de données pour obtenir le prochain nombre disponible pour les champs incrémentés automatiquement.

Utilisez cette commande pour générer le code SQL pouvant servir à corriger les situations où une séquence est désynchronisée par rapport aux données de son champ incrémenté automatiquement.

L’option --database peut être utilisée pour indiquer la base de données pour laquelle les instructions SQL doivent être affichées.

startapp <nom_app> [destination]

django-admin.py startapp

Crée une structure de répertoires d’application Django avec le nom d’application indiqué, dans le répertoire actuel ou dans la destination indiquée.

Par défaut, le répertoire créé contient un fichier models.py ainsi que d’autres fichiers modèles d’application (voir la source pour plus de détails). Si seul le nom d’application est indiqué, le répertoire de l’application sera créé dans le répertoire de travail actuel.

Si la destination facultative est indiquée, Django utilise ce répertoire existant plutôt que d’en créer un nouveau. Vous pouvez utiliser « . » pour signifier le répertoire de travail actuel.

Par exemple :

django-admin.py startapp myapp /Users/jezdez/Code/myapp
--template

Avec l’option --template, vous pouvez faire appel à un modèle de structure d’application personnalisé en fournissant soit le chemin vers un répertoire contenant le modèle d’application, soit un chemin vers un fichier compressé (.tar.gz, .tar.bz2, .tgz, .tbz, .zip) contenant les fichiers du modèle de structure d’application.

Par exemple, cette commande cherche un modèle d’application dans le répertoire indiqué lors de la création de l’application myapp:

django-admin.py startapp --template=/Users/jezdez/Code/my_app_template myapp

Django accepte également des URL (http, https, ftp) vers des archives compressées contenant les fichiers de modèle d’application, se chargeant de les télécharger et de les décompresser à la volée.

Par exemple, en profitant de la fonctionnalité de Github qui expose les dépôts sous forme de fichiers zip, vous pouvez utilisez une URL comme :

django-admin.py startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp

Lorsque Django copie les fichiers du modèle d’application, il fait aussi passer certains fichiers au travers du moteur de gabarit : les fichiers dont l’extension correspond à l’option --extension (py par défaut) et les fichiers dont les noms sont indiqués par l’option --name. Le contexte de gabarit utilisé est :

  • Toute option transmise à la commande startapp (parmi les options acceptées par la commande)

  • app_name – le nom d’application tel que transmis à la commande

  • app_directory – le chemin complet de l’application nouvellement créée

  • docs_version – la version de la documentation : 'dev' ou '1.x'

Avertissement

Lorsque les fichiers du modèle d’application sont générés avec le moteur de gabarit de Django (par défaut tous les fichiers *.py), Django remplace également toutes les variables de gabarit non ciblées. Par exemple, si l’un des fichiers Python contient une chaîne « docstring » expliquant une certaine fonctionnalité liée à la production de gabarit, cela pourrait produire un exemple incorrect.

Pour contourner ce problème, vous pouvez utiliser la balise de gabarit templatetag pour « échapper » les différentes parties de la syntaxe de gabarit.

startproject <nom_projet> [destination]

django-admin.py startproject

Crée une structure de répertoires de projet Django avec le nom de projet donné, dans le répertoire actuel ou la destination indiquée.

Par défaut, le nouveau répertoire contient manage.py est un paquet de projet (contenant settings.py et d’autres fichiers). Voir la source du modèle pour plus de détails.

Si seul le nom de projet est fourni, le répertoire de projet et le paquet de projet seront tous deux nommés <nom_projet> et le répertoire du projet sera créé dans le répertoire de travail actuel.

Si la destination facultative est fournie, Django utilise ce répertoire existant comme répertoire de projet, et crée manage.py ainsi que le paquet de projet à l’intérieur. Vous pouvez utiliser « . » pour signifier le répertoire de travail actuel.

Par exemple :

django-admin.py startproject myproject /Users/jezdez/Code/myproject_repo

Comme pour la commande startapp, l’option --template permet d’indiquer le répertoire, le chemin de fichier ou l’URL d’un modèle de projet personnalisé. Consultez la documentation de startapp pour plus de détails sur les formats de modèle de projet pris en charge.

Par exemple, cette commande cherche un modèle de projet dans le répertoire indiqué lors de la création du projet myproject:

django-admin.py startproject --template=/Users/jezdez/Code/my_project_template myproject

Django accepte également des URL (http, https, ftp) vers des archives compressées contenant les fichiers de modèle de projet, se chargeant de les télécharger et de les décompresser à la volée.

Par exemple, en profitant de la fonctionnalité de Github qui expose les dépôts sous forme de fichiers zip, vous pouvez utilisez une URL comme :

django-admin.py startproject --template=https://github.com/githubuser/django-project-template/archive/master.zip myproject

Lorsque Django copie les fichiers du modèle de projet, il fait aussi passer certains fichiers au travers du moteur de gabarit : les fichiers dont l’extension correspond à l’option --extension (py par défaut) et les fichiers dont les noms sont indiqués par l’option --name. Le contexte de gabarit utilisé est :

  • Toute option transmise à la commande startproject (parmi les options acceptées par la commande)

  • project_name – le nom du projet tel que transmis à la commande

  • project_directory – le chemin complet du projet nouvellement créé

  • secret_key – une clé aléatoire pour le réglage SECRET_KEY

  • docs_version – la version de la documentation : 'dev' ou '1.x'

Veuillez consultez également l’avertissement concernant le rendu mentionné pour la commande startapp.

syncdb

django-admin.py syncdb

Crée les tables de base de données pour toutes les applications de INSTALLED_APPS dont les tables n’ont pas encore été créées.

Utilisez cette commande lorsque vous avez ajouté de nouvelles applications à votre projet et que vous voulez créer les tables correspondantes dans la base de données. Cela inclut les applications livrées avec Django figurant par défaut dans INSTALLED_APPS. Lorsque vous commencez un nouveau projet, exécutez cette commande pour installer les applications par défaut.

Syncdb ne touche pas aux tables existantes

syncdb ne crée les tables que pour les modèles qui n’ont pas encore été installés. Elle n’exécute jamais d’instruction ALTER TABLE pour refléter des changements effectués dans une classe de modèle après son installation. Les modifications de classes de modèle et de schémas de base de données impliquent souvent certaines formes d’ambiguïté, et dans ces cas, Django devrait deviner les bons choix à faire. Ce processus risquerait de provoquer des pertes de données critiques.

Si vous avez effectué des modifications à un modèle et que vous voulez que les tables de base de données soient modifiées en conséquence, utilisez la commande sql pour afficher la nouvelle structure SQL et comparez le résultat à votre schéma de tables existant pour en déduire les modifications à appliquer.

Si vous avez installé l’application django.contrib.auth, syncdb vous donne l’option de créer immédiatement un super-utilisateur.

syncdb recherche et installe également tout instantané nommé initial_data doté d’une extension appropriée (par ex. json ou xml). Consultez la documentation de loaddata pour plus de détails sur la spécification des fichiers d’instantanés de données.

L’option --noinput peut être indiquée pour prévenir toute demande interactive à l’utilisateur.

L’option --database peut être utilisée pour indiquer la base de données qu’il s’agit de synchroniser.

--no-initial-data

New in Django 1.5.

Utilisez --no-initial-data pour éviter de charger les instantanés initial_data.

test <app ou identifiant_de_test>

django-admin.py test

Lance les tests de tous les modèles installés. Voir Les tests dans Django pour plus d’informations.

--failfast

L’option --failfast peut être utilisée afin que les tests s’interrompent immédiatement après l’échec d’un test, en affichant le rapport de l’échec.

--testrunner

L’option --testrunner peut être utilisée pour indiquer la classe de lancement de tests utilisée pour exécuter les tests. Si cette valeur est fournie, elle écrase la valeur contenue dans le réglage TEST_RUNNER.

--liveserver

L’option --liveserver peut être utilisée pour surcharger l’adresse par défaut que le serveur Web de test (utilisé avec LiveServerTestCase) est censé utiliser. La valeur par défaut est localhost:8081.

testserver <instantané instantané ...>

django-admin.py testserver

Lance un serveur de développement Django (comme avec runserver) en utilisant les données des instantanés indiqués.

Par exemple, cette commande :

django-admin.py testserver mydata.json

…effectue les opérations suivantes :

  1. Création d’une base de données de test, comme expliqué dans La base de données de test.

  2. Remplissage de la base de données de test avec les données d’instantanés à partir des noms d’instantanés indiqués (pour plus de détails sur les instantanés, voir la documentation de loaddata).

  3. Lancement du serveur de développement de Django (comme avec runserver), en utilisant la base de données de test venant d’être créée au lien de la base de données de production.

C’est utile dans plusieurs cas de figure :

  • Lorsque vous écrivez des tests unitaires sur les interactions entre les vues et certaines données, il est pratique de pouvoir lancer testserver afin d’interagir manuellement avec ces vues dans un navigateur Web.

  • Admettons que vous développez une application Django et que vous disposez d’une copie « en bon état » de la base de données avec laquelle vous souhaiteriez interagir. Vous pouvez exporter cette base de données dans un instantané (par la commande dumpdata détaillée ci-dessus), puis utiliser testserver pour lancer l’application Web avec ces données. Avec ce système, vous êtes libre de manipuler les données comme bon vous semble, sachant que toutes ces modifications ne se font que dans une base de données de test.

Notez que ce serveur ne détecte pas automatiquement les modifications de code source Python (comme le fait runserver). Il prend en compte par contre les modifications de gabarits.

--addrport [port number or ipaddr:port]

Utilisez --addrport pour indiquer un port ou une adresse IP et un port différent de la valeur par défaut 127.0.0.1:8000. Cette valeur respecte exactement le même format et joue exactement le même rôle que le paramètre donné à la commande runserver.

Exemples :

Pour lancer le serveur de test sur le port 7000 avec les données fixture1 et fixture2:

django-admin.py testserver --addrport 7000 fixture1 fixture2
django-admin.py testserver fixture1 fixture2 --addrport 7000

(Les commandes ci-dessus sont équivalentes. Nous les avons écrites les deux pour montrer que le placement des options avant ou après les paramètres d’instantanés n’a pas d’importance.)

Pour lancer un serveur sur 1.2.3.4:7000 avec un instantané test:

django-admin.py testserver --addrport 1.2.3.4:7000 test

L’option --noinput peut être indiquée pour prévenir toute demande interactive à l’utilisateur.

validate

django-admin.py validate

Valide tous les modèles installés (en respectant le réglage INSTALLED_APPS) et affiche les erreurs de validation dans la sortie standard.

Commandes fournies par les applications

Certaines commandes ne sont disponibles que lorsque l’application django.contrib qui les implémente a été activée. Cette section les présente de manière groupée par application.

django.contrib.auth

changepassword

django-admin.py changepassword

Cette commande n’est disponible que si le système d’authentification de Django (django.contrib.auth) est installé.

Permet de changer le mot de passe d’un utilisateur. Vous êtes invité à saisir deux fois le mot de passe de l’utilisateur indiqué en paramètre. Si les deux saisies correspondent, le nouveau mot de passe sera immédiatement défini. Si vous n’indiquez pas de nom d’utilisateur, la commande essaie de changer le mot de passe de l’utilisateur dont le nom correspond à l’utilisateur système en cours.

Utilisez l’option --database pour indiquer dans quelle base de données l’utilisateur doit être recherché. Par défaut, il s’agit de la base de données default.

Exemple d’utilisation :

django-admin.py changepassword ringo

createsuperuser

django-admin.py createsuperuser

Cette commande n’est disponible que si le système d’authentification de Django (django.contrib.auth) est installé.

Crée un compte super-utilisateur (un utilisateur ayant toutes les permissions). C’est utile si vous avez besoin de créer un compte de super-utilisateur mais que vous ne l’avez pas fait durant la commande syncdb, ou que vous avez besoin de générer des comptes de super-utilisateurs de manière programmable pour votre site.

Lorsqu’elle est exécutée de manière interactive, cette commande demande un mot de passe pour le nouveau compte super-utilisateur. En mode non interactif, aucun mot de passe n’est défini ; le compte super-utilisateur ne pourra pas se connecter tant qu’un mot de passe n’aura pas été manuellement défini pour ce compte.

--username
--email

Le nom d’utilisateur et l’adresse électronique du nouveau compte peuvent être fournis par le moyen des paramètres --username et --email en ligne de commande. Si ces paramètres ne sont pas renseignés, createsuperuser demande de les saisir en mode interactif.

L’option --database peut être utilisée pour indiquer la base de données dans laquelle l’objet super-utilisateur sera enregistré.

django.contrib.gis

ogrinspect

Cette commande n’est disponible que si GeoDjango (django.contrib.gis) est installé.

Veuillez vous référer à sa description dans la documentation de GeoDjango.

django.contrib.sessions

clearsessions

django-admin.py clearsessions
New in Django 1.5.

Peut être exécutée comme une commande « cron » ou directement pour nettoyer les sessions qui ont expiré.

django.contrib.sitemaps

ping_google

Cette commande n’est disponible que si l’infrastructure « sitemap » (django.contrib.sitemaps) est installée.

Veuillez vous référer à sa description dans la documentation de Sitemaps.

django.contrib.staticfiles

collectstatic

Cette commande n’est disponible que si l’application des fichiers statiques (django.contrib.staticfiles) est installée.

Veuillez vous référer à sa description dans la documentation des fichiers statiques.

findstatic

Cette commande n’est disponible que si l’application des fichiers statiques (django.contrib.staticfiles) est installée.

Veuillez vous référer à sa description dans la documentation des fichiers statiques.

Options par défaut

Même si certaines commandes définissent leurs propres options personnalisées, chaque commande accepte les options suivantes :

--pythonpath

Exemple d’utilisation :

django-admin.py syncdb --pythonpath='/home/djangoprojects/myproject'

Ajoute le chemin de système de fichier indiqué au chemin de recherche d’importation de Python. Quand cette option n’est pas renseignée, django-admin.py utilise la variable d’environnement PYTHONPATH.

Notez que cette option est inutile avec manage.py, parce que celui-ci s’occupe de définir le chemin Python à votre place.

--settings

Exemple d’utilisation :

django-admin.py syncdb --settings=mysite.settings

Définit explicitement le module de réglage (settings) à utiliser. Ce module doit être spécifié dans la syntaxe des paquets Python, par exemple monsite.settings. Quand cette option n’est pas renseignée, django-admin.py utilise la variable d’environnement DJANGO_SETTINGS_MODULE.

Notez que cette option n’est pas obligatoire avec manage.py, parce que celui-ci utilise par défaut le module settings.py du projet courant.

--traceback

Exemple d’utilisation :

django-admin.py syncdb --traceback

Par défaut, django-admin.py affiche un simple message d’erreur chaque fois qu’une erreur CommandError se produit, mais une trace de pile d’appels complète pour toute autre exception. Si vous indiquez --traceback, django-admin.py affiche également une trace de pile d’appels complète lorsqu’une erreur CommandError est générée.

Changed in Django 1.6:

Précédemment, Django n’affichait pas par défaut de trace de pile d’appels complète pour les exceptions autres que CommandError.

--verbosity

Exemple d’utilisation :

django-admin.py syncdb --verbosity 2

Utilisez --verbosity pour indiquer la quantité d’informations indicatives et de débogage que django-admin.py doit afficher dans la console.

  • 0 signifie aucun affichage.

  • 1 signifie un affichage normal (par défaut).

  • 2 signifie un affichage bavard.

  • 3 signifie un affichage très bavard.

Options communes

Les options suivantes ne sont pas disponibles pour toutes les commandes, mais elles sont partagées par plusieurs commandes.

--database

Utilisé pour indiquer la base de données sur laquelle va agir la commande. Quand elle n’est pas précisée, cette option contient par défaut l’alias default.

Par exemple, pour exporter les données de la base de données ayant l’alias master:

django-admin.py dumpdata --database=master
--exclude

Exclut une application spécifique des applications contenues dans l’affichage. Par exemple, pour exclure précisément l’application auth du résultat de dumpdata, il faut formuler ainsi :

django-admin.py dumpdata --exclude=auth

Pour exclure plusieurs applications, il est possible d’indiquer plusieurs fois la directive --exclude:

django-admin.py dumpdata --exclude=auth --exclude=contenttypes
--locale

Utilisez l’option --locale ou -l pour indiquer la langue à traiter. Sans information, toutes les langues sont traitées.

--noinput

Utilisez l’option --noinput pour supprimer toute demande interactive à l’utilisateur, comme par exemple un message de confirmation « Êtes-vous sûr ? ». C’est utile par exemple si django-admin.py est exécuté à partir d’un script automatisé.

Options complémentaires

Syntaxe colorée

Les commandes django-admin.py / manage.py présentent leur affichage avec un code de couleur visuellement attractif si le terminal prend en charge l’affichage coloré de type ANSI. Les codes de couleur ne sont pas utilisés dans le cas où vous redirigez le résultat d’une commande vers un autre programme.

Les couleurs utilisées pour la syntaxe colorée peuvent être personnalisées. Django contient trois palettes de couleurs :

  • dark (foncé), adaptée aux terminaux affichant du texte blanc sur fond noir. Il s’agit de la palette par défaut.

  • light (clair), adaptée aux terminaux affichant du texte noir sur fond blanc.

  • nocolor (sans couleur), qui désactive la syntaxe colorée.

Vous pouvez choisir la palette en définissant la variable d’environnement DJANGO_COLORS pour qu’elle contienne la palette désirée. Par exemple, pour définir la palette light dans un shell Bash de type Unix, voici ce qu’il faut saisir à l’invite de commande :

export DJANGO_COLORS="light"

Il est aussi possible de personnaliser les couleurs utilisées. Django définit un certain nombre de rôles utilisés par les couleurs :

  • error - Une erreur importante.

  • notice - Une petite erreur.

  • sql_field - Le nom d’un champ de modèle en SQL.

  • sql_coltype - Le type d’un champ de modèle en SQL.

  • sql_keyword - Un mot-clé SQL.

  • sql_table - Le nom d’un modèle en SQL.

  • http_info - Une réponse serveur HTTP de type information (1XX)

  • http_success - Une réponse serveur HTTP de type succès (2XX)

  • http_not_modified - Une réponse serveur HTTP de type non modifié (304)

  • http_redirect - Une réponse serveur HTTP de type redirection (3XX autre que 304).

  • http_not_found - Une réponse serveur HTTP non trouvé (404).

  • http_bad_request - Une réponse serveur HTTP de type mauvaise requête (4XX autre que 404).

  • http_server_error - Une réponse serveur HTTP de type erreur (5XX).

Chacun de ces rôles peut recevoir une couleur spécifique de premier plan ou d’arrière-plan, dans la liste suivante :

  • black (noir)

  • red (rouge)

  • green (vert)

  • yellow (jaune)

  • blue (bleu)

  • magenta
  • cyan
  • white (blanc)

Chacune de ces couleurs peut ensuite être modifiée en utilisant les options d’affichage suivantes :

  • bold (gras)

  • underscore (souligné)

  • blink (clignotant)

  • reverse
  • conceal (masqué)

Une spécification de couleur respecte l’un des motifs suivants :

  • role=fg
  • role=fg/bg
  • role=fg,option,option
  • role=fg/bg,option,option

role est le nom d’un rôle de couleur valide, fg est la couleur de premier plan, bg est la couleur d’arrière-plan et chaque option est l’une des options de modification de couleur. Plusieurs indications de couleurs sont ensuite séparées par des points-virgules. Par exemple :

export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"

indique que les erreurs doivent être affichées par un jaune clignotant sur du bleu et que les informations sont affichées en magenta. Tous les autres rôles de couleur sont sans couleur spécifique.

Les couleurs peuvent aussi être spécifiées en étendant une palette de base. Si vous indiquez un nom de palette dans une spécification de couleur, toutes les couleurs contenues dans cette palette seront chargées. Ainsi :

export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"

indique que toutes les couleurs de la palette claire doivent être utilisées, à l’exception des couleurs pour les erreurs et les informations qui sont surchargées comme indiqué.

Complétion Bash

Si vous utilisez le shell Bash, il est conseillé d’installer le script Django de complétion Bash qui se trouve dans extras/django_bash_completion de la distribution Django. Il active la complétion par tabulation des commandes django-admin.py et manage.py afin de pouvoir, par exemple…

  • Saisir django-admin.py.

  • Appuyer sur [TAB] pour voir toutes les options disponibles.

  • Saisir sql, puis [TAB], pour voir toutes les commandes disponibles dont le nom commence par sql.

Voir Écriture de commandes django-admin personnalisées pour savoir comment ajouter des actions personnalisées.

Lancement de commandes de gestion à partir du code

django.core.management.call_command(name, *args, **options)

Pour appeler une commande de gestion à partir du code, utilisez call_command.

name

le nom de la commande à appeler.

*args

une liste de paramètres acceptés par la commande.

**options

options nommées acceptées par la ligne de commande.

Exemples :

from django.core import management
management.call_command('flush', verbosity=0, interactive=False)
management.call_command('loaddata', 'test_data', verbosity=0)

Notez que les options de commandes qui n’acceptent pas de paramètre sont transmises sous forme de mots-clés avec True ou False:

management.call_command('dumpdata', use_natural_keys=True)

Les options de commandes acceptant plusieurs options sont transmises sous forme de liste :

management.call_command('dumpdata', exclude=['contenttypes', 'auth'])

Redirection en sortie

Notez que vous pouvez rediriger la sortie standard et les flux d’erreur car toutes les commandes acceptent les options stdout et stderr, Par exemple, vous pouvez écrire :

with open('/tmp/command_output') as f:
    management.call_command('dumpdata', stdout=f)