django-admin et manage.py

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

De plus, manage.py est créé automatiquement dans chaque projet Django.``manage.py`` fait la même chose que django-admin mais se charge de plusieurs choses à votre place :

• 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 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.exe 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. 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.

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

Utilisation

$ django-admin <command> [options]
$ manage.py <command> [options]
$ python -m django <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 help

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

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

Lancez django-admin 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 version

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

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

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 affiche dans la console.

Commandes disponibles

check

django-admin check [app_label [app_label ...]]

Utilise l”infrastructure de contrôle système pour inspecter le projet Django dans son intégralité à la recherche de problèmes courants.

Par défaut, toutes les applications sont contrôlées. Vous pouvez vérifier un sous-ensemble d’applications en fournissant une liste d’étiquettes d’application en paramètres :

django-admin check auth admin myapp

Si vous n’indiquez aucune application, toutes les applications sont contrôlées.

--tag TAGS, -t TAGS

L’infrastructure de contrôle système effectue de nombreux types de contrôles qui sont catégorisés par des étiquettes. Celles-ci permettent de limiter les contrôles effectués à ceux d’une catégorie particulière. Par exemple, pour n’effectuer que les contrôles de modèles et de compatibilité, exécutez :

django-admin check --tag models --tag compatibility

--list-tags

Affiche la liste de toutes les étiquettes disponibles.

--deploy

Active certains contrôles supplémentaires qui ne sont valables que pour des réglages de déploiement.

Vous pouvez utiliser cette option dans votre environnement local de développement, mais comme vos réglages de développement local ne contiennent pas forcément beaucoup de réglages de production, il est généralement souhaitable de faire pointer la commande check vers un autre module de réglages, soit en définissant la variable d’environnement DJANGO_SETTINGS_MODULE, soit en passant l’option --settings:

django-admin check --deploy --settings=production_settings

Ou vous pouvez la lancer directement dans un système en production ou préproduction pour vérifier que les bons réglages sont définis (en omettant --settings). Il est même possible d’intégrer la commande dans votre suite de tests d’intégration.

--fail-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}

New in Django 1.10.

Définit le niveau de message qui produira la sortie de la commande avec un code d’état différent de zéro. La valeur par défaut est ERROR.

compilemessages

django-admin compilemessages

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

--locale LOCALE, -l LOCALE

Indique la ou les langues à traiter. Sans information, toutes les langues sont traitées.

--exclude EXCLUDE, -x EXCLUDE

Indique les langues à exclure du traitement de la commande. Sans autre information, aucune langue n’est exclue.

--use-fuzzy, -f

Inclut les traductions approximatives (« fuzzy ») dans les fichiers compilés.

Exemple d’utilisation :

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

createcachetable

django-admin createcachetable

Crée les tables de cache à l’usage du moteur de cache en base de données en utilisant les informations du fichier des réglages. Voir L’infrastructure de cache dans Django pour plus d’informations.

--database DATABASE

Indique la base de données dans laquelle la table de cache sera créée. La valeur par défaut est default.

--dry-run

Affiche le code SQL qui sera exécuté sans réellement l’exécuter, de sorte que vous pouvez le personnaliser ou utiliser le système des migrations.

dbshell

django-admin 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.
• Pour Oracle, cette commande lance le client en ligne de commande sqlplus.

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, sqlplus), le bon programme est lancé. Il n’y a pas d’astuce pour indiquer manuellement le chemin du programme de base de données.

--database DATABASE

Indique la base de données pour laquelle le shell doit être ouvert. La valeur par défaut est 'default'.

diffsettings

django-admin diffsettings

Affiche les différences entre le fichier de réglages actuel et les réglages par défaut de Django (ou un autre fichier de réglages indiqué par --default).

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.

--all

Affiche 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 "###".

--default MODULE

New in Django 1.11.

Le module de réglages avec lequel comparer les réglages en cours. Laissez vide pour comparer avec les réglages par défaut de Django.

dumpdata

django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName] ...]]

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.

--all, -a

Utilise 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 FORMAT

Indique le format de sérialisation du résultat. Par défaut, il s’agit de JSON. Les formats pris en charge sont énumérés dans Formats de sérialisation.

--indent INDENT

Indique le nombre d’espaces d’indentation à utiliser pour le résultat. Par défaut, il n’y en a aucun, ce qui fait que toutes les données s’affichent sur une seule ligne.

--exclude EXCLUDE, -e EXCLUDE

Empêche certaines applications ou modèles (désignés sous la forme étiquette_app.NomModèle) d’être affichés. Si vous indiquez un nom de modèle, 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.

Pour exclure plusieurs applications, indiquez plusieurs fois --exclude:

django-admin dumpdata --exclude=auth --exclude=contenttypes

--database DATABASE

Indique la base de données à partir de laquelle les données seront produites. La valeur par défaut est 'default'.

--natural-foreign

Utilise la méthode de modèle natural_key() pour sérialiser d’éventuelles relations de clé étrangères ou plusieurs-à-plusieurs vers des objets du type que définit la méthode. Si vous exportez des objets Permission de contrib.auth ou des objets ContentType de contrib.contenttypes, il est recommandé d’utiliser cette option. Consultez la documentation sur les clés naturelles pour plus de détails sur cette option et la suivante.

--natural-primary

Omet la clé primaire dans les données sérialisées de cet objet dans la mesure où elle peut être calculée durant la désérialisation.

--pks PRIMARY_KEYS

N’affiche que les objets désignés par 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. Par défaut, touts les enregistrements du modèle sont exportés.

--output OUTPUT, -o OUTPUT

Indique le fichier dans lequel les données sérialisées doivent être écrites. Par défaut, les données s’affichent sur la sortie standard.

Lorsque cette option est définie et que --verbosity est plus grande que 0 (par défaut), une barre de progression s’affiche dans le terminal.

flush

django-admin flush

Supprime toutes les données de la base de données et réexécute tout gestionnaire de post-synchronisation. La table contenant les informations d’application des migrations n’est pas effacée.

Si vous préférez repartir d’une base de données vide et rejouer toutes les migrations, il est plutôt conseillé de supprimer et recréer la base de données, puis d’exécuter migrate.

--noinput, --no-input

Évite toute demande interactive à l’utilisateur.

--database DATABASE

Indique la base de données qu’il s’agit de réinitialiser. La valeur par défaut est default.

inspectdb

django-admin inspectdb [table [table ...]]

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. Il est possible de choisir les tables à inspecter en passant leur nom en paramètre.

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 ne crée pas de valeur par défaut en base de données lorsqu’un paramètre default est défini pour un champ de modèle. Inversement, les valeurs par défaut en base de données ne sont pas traduites en valeurs par défaut de champ de modèle, ni détecté d’aucune autre façon par

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 modification ou 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).

New in Django 1.10:

La prise en charge du paramètre table pour indiquer les tables à inspecter a été ajoutée.

--database DATABASE

Indique la base de données qu’il s’agit d’examiner. La valeur par défaut est default.

loaddata

django-admin loaddata fixture [fixture ...]

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

--database DATABASE

Indique la base de données dans laquelle les données seront chargées. La valeur par défaut est default.

--ignorenonexistent, -i

Ignore les champs et les modèles qui pourraient avoir été enlevés depuis que l’instantané a été initialement produit.

--app APP_LABEL

Désigne une seule application dans laquelle rechercher des instantanés au lieu de chercher dans toutes les applications.

--exclude EXCLUDE, -e EXCLUDE

New in Django 1.11.

Exclut le chargement des instantanés des applications et modèles indiqués (sous la forme étiquette_app ou `` étiquette_app.NomModèle``). L’option peut être indiquée plusieurs fois pour exclure plus d’une application ou modèle.

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 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 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 loaddata foo/bar/mydata.json

recherche <étiquette_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 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 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.

Cette commande ne demande pas de réglages configurés. Cependant, lorsque les réglages ne sont pas configurés, la commande ne peut pas ignorer les répertoires MEDIA_ROOT et STATIC_ROOT, ni inclure LOCALE_PATHS. Elle écrit aussi les fichiers en UTF-8 sans prendre en compte FILE_CHARSET.

--all, -a

Met à jour les fichiers de messages pour toutes les langues disponibles.

--extension EXTENSIONS, -e EXTENSIONS

Indique une liste d’extensions de fichiers à examiner (par défaut : html, txt, py ou js si --domain vaut js).

Exemple d’utilisation :

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

Séparez plusieurs extensions par une virgule ou utilisez plusieurs occurrences de -e ou --extension:

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

--locale LOCALE, -l LOCALE

Indique les langues à traiter.

--exclude EXCLUDE, -x EXCLUDE

Indique les langues à exclure du traitement de la commande. Sans autre information, aucune langue n’est exclue.

Exemple d’utilisation :

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

--domain DOMAIN, -d DOMAIN

Indique le domaine des fichiers de messages. Les options acceptées sont :

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

--symlinks, -s

Suit les liens symboliques vers les répertoires lors de la recherche de nouvelles chaînes à traduire.

Exemple d’utilisation :

django-admin makemessages --locale=de --symlinks

--ignore PATTERN, -i PATTERN

Ignore 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', '.*', '*~', '*.pyc'.

Exemple d’utilisation :

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

--no-default-ignore

Désactive les valeurs par défaut de --ignore.

--no-wrap

Désactive la segmentation des longues lignes de messages sur plusieurs lignes dans les fichiers de langues.

--no-location

Supprime l’écriture des lignes de commentaire #: filename:line dans les fichiers de langues. Avec cette option, les traducteurs ayant de bonnes notions techniques auront plus de peine à saisir le contexte de chaque message.

--keep-pot

Empêche la suppression des fichiers .pot temporaires générés 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.

Voir aussi

Consultez Personnalisation de la commande makemessages pour des instructions sur la façon de personnaliser les mots-clés que makemessages transmet à xgettext.

makemigrations

django-admin makemigrations [app_label [app_label ...]]

Crée de nouvelles migrations sur la base des modifications détectées dans les modèles. Les migrations, leurs relations avec les applications et d’autre sujets encore sont abordés en détails dans la documentation sur les migrations.

En indiquant un ou plusieurs noms d’applications en paramètre limite la création de migrations aux applications désignées ainsi qu’à leurs dépendances (la table à l’autre bout d’une clé ForeignKey, par exemple).

Pour ajouter des migrations à une application qui n’a pas de répertoire migrations, lancez makemigrations avec l’étiquette de l’application en paramètre.

--noinput, --no-input

Supprime toute demande à l’utilisateur. SI une demande supprimée ne peut pas être résolue automatiquement, la commande se termine avec le code d’erreur 3.

--empty

Produit une migration vide pour les applications données, en vue d’une modification manuelle. Cette option est réservée aux utilisateurs avancés et ne devrait pas être utilisée sans être familier du format des migrations, des opérations de migration et des dépendances entre les migrations.

--dry-run

Montre les migrations qui seraient produites mais sans écrire réellement de fichier de migration sur le disque. L’emploi de cette option accompagnée de --verbosity 3 montre également les fichiers de migrations complets tels qu’ils seraient écrits.

--merge

Active la résolution des conflits de migration.

--name NAME, -n NAME

Permet de donner aux migrations un nom de votre choix au lieu de celui qui est généré automatiquement.

--exit, -e

Obsolète depuis la version 1.10: Utilisez plutôt l’option --check.

Demande à makemigrations de quitter avec un code d’erreur 1 lorsqu’aucune migration n’est créée (ou n’aurait été créée, quand elle est combinée avec --dry-run).

--check

New in Django 1.10.

Fait quitter makemigrations avec un statut différent de 0 lorsque des modifications de modèles sans migration correspondante sont détectés.

migrate

django-admin migrate [app_label] [migration_name]

Actualise l’état de la base de données en accord avec l’ensemble des modèles et des migrations actuels. Les migrations, leurs relations avec les applications et d’autre sujets encore sont abordés en détails dans la documentation sur les migrations.

Le comportement de cette commande change en fonction des paramètres fournis :

• Pas de paramètre : toutes les applications appliquent toutes leurs migrations.
• <étiquette_app>: les migrations de l’application indiquée sont appliquées jusqu’à la migration la plus récente. Cela peut aussi provoquer l’application des migrations d’autres applications, en fonction des dépendances.
• <étiquette_app> <nom_migration>: fait passer le schéma de base de données à l’état où la migration indiquée est appliquée, mais sans que les migrations ultérieures de la même application ne soient appliquées ; ceci peut conduire à défaire certaines migrations si les migrations postérieures à la migration nommée ont déjà été appliquées. Utilisez le nom zero pour défaire toutes les migrations d’une application.

--database DATABASE

Désigne la base de données à migrer. La valeur par défaut est 'default'.

--fake

Demande à Django de marquer les migrations comme ayant été appliquées ou défaites, mais sans lancer réellement d’instructions SQL pour modifier le schéma de base de données.

Ceci est destiné aux utilisateurs avancés pour manipuler directement l’état actuel des migrations dans le cas où ils appliquent manuellement certains changements ; soyez conscient que l’emploi de --fake crée le risque de placer la table des états de migration dans un état où une intervention manuelle deviendra indispensable pour que les migrations puissent de nouveau fonctionner correctement.

--fake-initial

Permet à Django de sauter la migration initiale d’une application si toutes les tables de base de données avec les noms de tous les modèles créés par toutes les opérations CreateModel de cette migration existent déjà. Cette option est prévue pour le premier lancement des migrations sur une base de données qui existait déjà avant l’utilisation des migrations. Cependant, à part le nom des tables, cette option ne vérifie pas que le schéma de base de données corresponde exactement aux modèles, ce qui signifie qu’elle ne doit être utilisée qui si vous savez pertinemment que le schéma actuel correspond bel et bien à ce qui est enregistré dans la migration initiale.

--run-syncdb

Permet de créer les tables des applications sans migrations. Bien que ce ne soit pas recommandé, le système des migrations est parfois trop lent avec de grands projets qui ont des centaines de modèles.

--noinput, --no-input

Supprime toute demande interactive à l’utilisateur. Un exemple de demande pourrait concerner la suppression des types de contenus obsolètes.

runserver

django-admin runserver [addrport]

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 ne provoquent pas de redémarrage, il est donc nécessaire de redémarrer manuellement le serveur dans ces cas.

Si vous utilisez Linux et que vous installez pyinotify, ce sont des signaux du noyau qui permettent de recharger automatiquement le serveur (au lieu de consulter chaque seconde les dates de modification des fichiers). Les avantages offerts sont une meilleure adaptation aux gros projets, un temps de réponse réduit après les modifications de code, une détection des changements plus robuste et une réduction de consommation de la batterie.

Au démarrage du serveur et lors de chaque modification de code Python durant le fonctionnement du serveur, l’infrastructure de contrôle système recherche d’éventuelles erreurs courantes dans tout le projet Django (voir la commande check). Si des erreurs sont détectées, celles-ci sont affichées dans la sortie standard.

Vous pouvez lancer autant de serveurs en parallèle que nécessaire, pour autant que ce soit sur des ports séparés. Il suffit d’exécuter plusieurs fois django-admin 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.

Si migrate n’a pas encore été exécuté une première fois, la table qui stocke l’historique des migrations est créée au premier lancement de runserver.

La journalisation de chaque requête et réponse du serveur est envoyée au journaliseur django.server.

Changed in Django 1.10:

Dans les versions précédentes, les messages de journal étaient envoyés à sys.stderr au lieu d’être gérés par la journalisation Python.

--noreload

Désactive 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.

--nothreading

Désactive l’utilisation des fils d’exécution avec le serveur de développement. Par défaut, le serveur utilise plusieurs fils d’exécution (multithread).

--ipv6, -6

Utilise IPv6 pour le serveur de développement. L’adresse IP par défaut passe alors de 127.0.0.1 à ::1.

Exemples d’utilisation de différents ports et adresses

Port 8000 sur l’adresse IP 127.0.0.1:

django-admin runserver

Port 8000 sur l’adresse IP 1.2.3.4:

django-admin runserver 1.2.3.4:8000

Port 7000 sur l’adresse IP 127.0.0.1:

django-admin runserver 7000

Port 7000 sur l’adresse IP 1.2.3.4:

django-admin runserver 1.2.3.4:7000

Port 8000 sur l’adresse IPv6 ::1:

django-admin runserver -6

Port 7000 sur l’adresse IPv6 ::1:

django-admin runserver -6 7000

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

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

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

django-admin runserver localhost:8000

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

django-admin 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 (par ex. images, JavaScript, CSS).

sendtestemail

django-admin sendtestemail [email [email ...]]

Envoie un courriel de test (pour confirmer le bon fonctionnement de l’envoi de messages avec Django) aux destinataires indiqués. Par exemple :

django-admin sendtestemail [e-mail] [e-mail]

Il y a plusieurs options possibles, et vous pouvez combiner ces options sans problème :

--managers

Envoie le courriel aux adresses électroniques figurant dans MANAGERS avec mail_managers().

--admins

Envoie le courriel aux adresses électroniques figurant dans ADMINS avec mail_admins().

shell

django-admin shell

Lance l’interpréteur interactif Python.

--interface {ipython,bpython,python}, -i {ipython,bpython,python}

Indique le shell à utiliser. Par défaut, Django utilise IPython ou bpython s’ils sont installés. Si les deux sont installés, vous pouvez indiquer l’interpréteur souhaité comme ceci :

IPython :

django-admin shell -i ipython

bpython :

django-admin shell -i bpython

Si vous avez l’un de ces shells « enrichis » installé mais que vous aimeriez lancer l’interpréteur « brut » de Python, utilisez python comme nom d’interface, comme ceci :

django-admin shell -i python

Obsolète depuis la version 1.10: Dans les versions précédentes, il fallait utiliser l’option --plain plutôt que -i python. Cette ancienne syntaxe est maintenant obsolète et sera supprimée dans Django 2.0.

--nostartup

Désactive la lecture du script de démarrage pour l’interpréteur Python « simple ». Par défaut, le script lu est celui qui est désigné par la variable d’environnement PYTHONSTARTUP ou le script ~/.pythonrc.py.

--command COMMAND, -c COMMAND

New in Django 1.10.

Permet de transmettre une commande sous forme de texte à exécuter par Django, comme ceci :

django-admin shell --command="import django; print(django.__version__)"

Vous pouvez aussi passer du code par l’entrée standard afin de l’exécuter. Par exemple :

$ django-admin shell <<EOF
> import django
> print(django.__version__)
> EOF

Avec Windows, REPL est affiché en raison des limites d’implémentation de select.select() sur cette plateforme.

Changed in Django 1.11:

Dans les versions précédentes, REPL était aussi affiché avec les systèmes UNIX.

showmigrations

django-admin showmigrations [app_label [app_label ...]]

Affiche toutes les migrations d’un projet. Vous pouvez choisir l’un des deux formats suivants :

--list, -l

Énumère toutes les applications connues par Django, les migrations disponibles pour chaque application et l’état d’application de chaque migration (marqué par un [X] à côté du nom de la migration).

Les applications sans migration sont également comprises dans la liste, mais le texte (no migrations) s’affiche sous leur nom.

Il s’agit du format d’affichage par défaut.

--plan, -p

Montre le plan de migration que Django va suivre pour appliquer les migrations. Comme pour --list, les migrations appliquées sont marquées par une [X]. Quand la verbosité est plus grande que 1, toutes les dépendances d’une migration sont également affichées.

Les paramètres app_label limitent les résultats affichés, mais il est tout de même possible que des dépendances des applications indiquées soient aussi incluses.

Changed in Django 1.11:

Dans les versions précédentes, showmigrations --plan ignorait les étiquettes d’application.

--database DATABASE

Indique la base de données à examiner. La valeur par défaut est default.

sqlflush

django-admin sqlflush

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

--database DATABASE

Indique la base de données pour laquelle les instructions SQL doivent être affichées. La valeur par défaut est default.

sqlmigrate

django-admin sqlmigrate app_label migration_name

Affiche le code SQL correspondant à la migration nommée. Cela demande une connexion active à la base de données, que la commande utilise pour résoudre les noms de contraintes ; cela signifie que vous devez générer le code SQL par rapport à une copie de la base de données à laquelle vous souhaitez plus tard appliquer le résultat.

Remarquez que sqlmigrate ne colore pas le résultat produit.

--backwards

Génère le code SQL servant à défaire la migration. Par défaut, le code SQL créé est celui qui sert à appliquer la migration dans le sens progressif.

--database DATABASE

Indique la base de données pour laquelle les instructions SQL doivent être générées. La valeur par défaut est default.

sqlsequencereset

django-admin sqlsequencereset app_label [app_label ...]

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.

--database DATABASE

Indique la base de données pour laquelle les instructions SQL doivent être affichées. La valeur par défaut est default.

squashmigrations

django-admin squashmigrations app_label [start_migration_name] migration_name

Fusionne les migrations de étiquette_app jusqu’à et y compris nom_migration en un nombre plus restreint de migrations, si possible. Les migrations fusionnées résultantes peuvent figurer sans problème au côté des migrations non fusionnées. Pour plus d’informations, veuillez lire Fusion de migrations.

Lorsque start_migration_name est indiqué, Django n’inclut que les migrations commençant par cette migration y comprise. Cela aide à relativiser les limites du fusionnement des opérations de migration RunPython et django.db.migrations.operations.RunSQL.

--no-optimize

Désactive l’optimiseur lors de la génération d’une migration fusionnée. Par défaut, Django essaie d’optimiser les opérations dans les migrations pour réduire la taille du fichier résultant. Utilisez cette option si ce processus échoue ou qu’il crée des migrations incorrectes. Dans ce cas, Il serait toutefois aussi souhaitable de remplir un rapport d’anomalie pour Django car cette optimisation est censée être sûre.

--noinput, --no-input

Évite toute demande interactive à l’utilisateur.

startapp

django-admin startapp name [directory]

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 startapp myapp /Users/jezdez/Code/myapp

--template TEMPLATE

Fournit le chemin vers un répertoire contenant un modèle d’application personnalisé ou 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 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 startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp

--extension EXTENSIONS, -e EXTENSIONS

Indique les extensions de fichiers dans le modèle d’application qui doivent être produits par le moteur de gabarit. py par défaut.

--name FILES, -n FILES

Indique les fichiers du modèle d’application (en plus de ceux correspondant à --extension) qui doivent être produits par le moteur de gabarit. Par défaut, c’est une liste vide.

Le contexte de gabarit utilisé pour tous les fichiers concernés 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
• camel_case_app_name – le nom d’application au format CamelCase
• 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.

En plus, pour permettre aux fichiers gabarits Python de contenir de la syntaxe du langage de gabarit de Django tout en empêchant les systèmes d’empaquetage d’essayer de précompiler ces fichiers *.py non valides syntaxiquement, les fichiers de gabarit se terminant par .py-tpl seront renommés en .py.

startproject

django-admin startproject name [directory]

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 startproject myproject /Users/jezdez/Code/myproject_repo

--template TEMPLATE

Indique un répertoire, un chemin de fichier ou l’URL d’un modèle de projet personnalisé. Consultez la documentation de startapp --template pour des exemples d’utilisation.

--extension EXTENSIONS, -e EXTENSIONS

Indique les extensions de fichiers dans le modèle de projet qui doivent être produits par le moteur de gabarit. py par défaut.

--name FILES, -n FILES

Indique les fichiers du modèle de projet (en plus de ceux correspondant à --extension) qui doivent être produits par le moteur de gabarit. Par défaut, c’est une liste vide.

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.

test

django-admin test [test_label [test_label ...]]

Lance les tests de toutes les applications installées. Voir Les tests dans Django pour plus d’informations.

--failfast

Interrompt l’exécution des tests et affiche le rapport de l’échec immédiatement après l’échec d’un test.

--testrunner TESTRUNNER

Indique la classe de lancement de tests utilisée pour exécuter les tests. Cette valeur écrase la valeur contenue dans le réglage TEST_RUNNER.

--noinput, --no-input

Supprime toute demande interactive à l’utilisateur. Une demande typique concerne par exemple l’avertissement de suppression d’une base de données de test existante.

Options du lanceur de tests

La commande test reçoit des options de la part du lanceur de tests --testrunner indiqué. Ces options sont celles du lanceur de tests par défaut : DiscoverRunner.

--keepdb, -k

Préserve la base de données de test entre les lancements des tests. Cela présente l’avantage de sauter à la fois les actions de création et de destruction, ce qui peut fortement diminuer le temps de fonctionnement des tests, particulièrement dans le cadre d’une grosse suite de test. Si la base de données de test n’existe pas, elle sera créée au premier lancement et conservée ensuite pour chaque lancement subséquent. Toute migration non appliquée sera aussi appliquée à la base de données de test avant de lancer la suite de tests.

--reverse, -r

Trie les cas de tests dans l’ordre d’exécution inverse. Cela peut aider à déboguer des effets de bord dans les tests qui ne sont pas isolés correctement. Le groupement par classe de test est conservé lors de l’utilisation de cette option.

--debug-mode

New in Django 1.11.

Définit le réglage DEBUG à True avant d’exécuter les tests. Cela peut aider à investiguer les échecs de tests.

--debug-sql, -d

Active la journalisation SQL des tests qui échouent. Si --verbosity vaut 2, les requêtes dans les tests qui réussissent sont aussi affichées.

--parallel [N]

Exécute les tests en parallèle dans des processus séparés. Comme les processeurs modernes ont plusieurs cœurs, cela permet de rendre les tests nettement plus rapides.

Par défaut, --parallel exécute un processus par cœur en fonction de multiprocessing.cpu_count(). Vous pouvez ajuster le nombre de processus soit en indiquant un nombre à l’option, par ex. --parallel=4, soit en définissant la variable d’environnement DJANGO_TEST_PROCESSES.

Django distribue les cas de test (sous-classes de unittest.TestCase) à des sous-processus. S’il y a moins de cas de test que de processus configurés, Django réduit le nombre de processus en conséquence.

Chaque processus travaille avec sa propre base de données. Vous devez vous assurer que les différents cas de test n’accèdent pas aux mêmes ressources. Par exemple, les cas de test qui touchent au système de fichiers devraient créer un répertoire temporaire pour leur propre usage.

Cette option nécessite le paquet externe tblib pour afficher correctement les piles d’appels :

$ pip install tblib

Cette fonctionnalité n’est pas disponible sur Windows. Elle ne fonctionne pas non plus avec les bases de données Oracle.

Si vous souhaitez utiliser pdb pendant le débogage des tests, vous devez désactiver l’exécution en parallèle (--parallel=1). Si vous ne le faites pas, vous verrez quelque chose comme bdb.BdbQuit.

Avertissement

Lorsque la parallélisation des tests est activée et qu’un test échoue, il se peut que Django ne puisse pas afficher la pile d’appels de l’exception. Cela peut rendre le débogage difficile. Si vous rencontrez ce problème, exécutez le test concerné sans parallélisation pour voir la pile d’appels de l’échec.

Il s’agit d’une limitation connue. Elle provient du besoin de sérialisation des objets pour pouvoir les échanger entre processus. Voir What can be pickled and unpickled? pour plus de détails.

--tag TAGS

New in Django 1.10.

N’exécute que les tests marqués avec les étiquettes mentionnées. Plusieurs occurrences sont possibles et la combinaison est possible avec test --exclude-tag.

--exclude-tag EXCLUDE_TAGS

New in Django 1.10.

Exclut les tests marqués avec les étiquettes mentionnées. Plusieurs occurrences sont possibles et la combinaison est possible avec test --tag.

testserver

django-admin testserver [fixture [fixture ...]]

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 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 ADDRPORT

Indique 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 testserver --addrport 7000 fixture1 fixture2
django-admin 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 testserver --addrport 1.2.3.4:7000 test

--noinput, --no-input

Supprime toute demande interactive à l’utilisateur. Une demande typique concerne par exemple l’avertissement de suppression d’une base de données de test existante.

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 changepassword [<username>]

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é. 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.

--database DATABASE

Indique 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 changepassword ringo

createsuperuser

django-admin 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 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 USERNAME

--email 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.

--database DATABASE

Indique la base de données dans laquelle l’objet super-utilisateur sera enregistré.

Vous pouvez créer une sous-classe de la commande d’administration et surcharger get_input_data() si vous souhaitez personnaliser la saisie de données et la validation. Examinez le code source pour des détails sur l’implémentation existante et les paramètres de la méthode. Par exemple, cela pourrait être utile si vous avez une clé ForeignKey dans REQUIRED_FIELDS et que vous voulez permettre la création d’une instance au lieu de devoir saisir la clé primaire d’une instance existante.

django.contrib.contenttypes

remove_stale_contenttypes

django-admin remove_stale_contenttypes

New in Django 1.11.

Cette commande n’est disponible que si l”application « contenttypes » (django.contrib.contenttypes) est installée.

Supprime les types de contenu obsolètes (provenant de modèles supprimés) de la base de données. Tout objet dépendant des types de contenu supprimés sera aussi détruit. Une liste des objets supprimés sera affichée avant de confirmer que la suppression peut se poursuivre.

--database DATABASE

Indique la base de données à utiliser. La valeur par défaut est default.

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 clearsessions

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 PYTHONPATH

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 utilise la variable d’environnement PYTHONPATH.

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

Exemple d’utilisation :

django-admin migrate --pythonpath='/home/djangoprojects/myproject'

--settings SETTINGS

Définit 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 utilise la variable d’environnement DJANGO_SETTINGS_MODULE.

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

Exemple d’utilisation :

django-admin migrate --settings=mysite.settings

--traceback

Affiche une trace de pile d’appels complète lorsqu’une exception CommandError apparaît. Par défaut, django-admin affiche un simple message d’erreur chaque fois qu’une erreur CommandError se produit, et une trace de pile d’appels complète pour toute autre exception.

Exemple d’utilisation :

django-admin migrate --traceback

--verbosity {0,1,2,3}, -v {0,1,2,3}

Indique la quantité d’informations indicatives et de débogage qu’une commande 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.

Exemple d’utilisation :

django-admin migrate --verbosity 2

--no-color

Désactive l’affichage coloré du résultat des commandes. Certaines commandes mettent en forme leur résultat en couleurs. Par exemple, les erreurs affichées dans la console sont en rouge et la syntaxe des instructions SQL est colorée.

Exemple d’utilisation :

django-admin runserver --no-color

Options complémentaires

Syntaxe colorée

Les commandes django-admin / 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.

Avec Windows, la console native ne prend pas en charge les séquences d’échappement ANSI, ce qui fait que le résultat n’est pas coloré. Vous pouvez toutefois installer l’outil externe ANSICON que les commandes Django vont détecter et utiliser pour produire des sorties colorées comme pour les plates-formes de type Unix.

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.
• success - Un succès.
• warning - Un avertissement.
• 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).
• migrate_heading - Un en-tête dans une commande d’administration de migration.
• migrate_label - Un nom de migration.

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

où 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 et manage.py afin de pouvoir, par exemple…

• Saisissez django-admin.
• 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 ou un objet commande. La transmission du nom est préférée, sauf si l’objet est obligatoire pour les tests.

*args

une liste de paramètres acceptés par la commande. Les paramètres sont transmis à l’analyseur de paramètres, ce qui signifie qu’on peut utiliser le même style que dans la ligne de commande. Par exemple, call_command('flush', '--verbosity=0').

**options

options nommées acceptées dans la ligne de commande. Les options sont transmises à la commande sans faire appel à l’analyseur de paramètres, ce qui signifie qu’il est nécessaire de passer le bon type. Par exemple, call_command('flush', verbosity=0) (zéro doit être un entier et non pas une chaîne).

Exemples :

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)

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, comme vous pouvez le voir avec l’option interactive ci-dessus.

Les paramètres nommés peuvent être transmis en utilisant l’une des syntaxes suivantes :

# 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)

Certaines options de commande sont nommées différemment quand les commandes sont appelées avec call_command() au lieu de django-admin ou manage.py. Par exemple, django-admin createsuperuser --no-input se traduit par call_command('createsuperuser', interactive=False). Pour savoir quel nom de paramètre nommé utiliser pour call_command(), consultez le code source de la commande et cherchez le paramètre dest passé à parser.add_argument().

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

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

La valeur renvoyée par la fonction call_command() est la même que celle renvoyée par la méthode handle() de la commande.

Changed in Django 1.10:

call_command() renvoie dorénavant la valeur reçue de la méthode command.handle(). Elle accepte aussi un objet commande comme premier paramètre.

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('/path/to/command_output') as f:
    management.call_command('dumpdata', stdout=f)