--- title: "django-admin et manage.py" version: 6.1 locale: fr source: https://docs.djangoproject.com/fr/6.1/ref/django-admin/ canonical: https://djangodocs.dev/fr/6.1/ref/django-admin/ --- # `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. Il fait la même chose que `django-admin` mais définit également la variable d’environnement [`DJANGO_SETTINGS_MODULE`](/fr/6.1/topics/settings/#envvar-DJANGO_SETTINGS_MODULE) pour la faire pointer sur le fichier `settings.py` du projet. Le script `django-admin` devrait se trouver dans votre chemin système si vous avez installé Django via `pip`. S’il ne se trouve pas dans votre chemin, vérifiez que votre environnement virtuel est activé. 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`](/fr/6.1/topics/settings/#envvar-DJANGO_SETTINGS_MODULE) ou l’option de ligne de commande [`--settings`](#cmdoption-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 ```console $ django-admin [options] $ manage.py [options] $ python -m django [options] ``` *Windows* ```doscon ...\> django-admin [options] ...\> manage.py [options] ...\> py -m django [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 ` 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`](/fr/6.1/ref/settings/#std-setting-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**](https://peps.python.org/pep-0440/): ```text 1.4.dev17026 1.4a1 1.4 ``` ### Affichage du contenu de débogage Utilisez [`--verbosity`](#cmdoption-verbosity), le cas échéant, 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](/fr/6.1/ref/checks/) 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 : ```console django-admin check auth admin myapp ``` #### `--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](/fr/6.1/ref/checks/#system-check-builtin-tags). 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 : ```console django-admin check --tag models --tag compatibility ``` #### `--database DATABASE` Indique la base de données pour laquelle effectuer les contrôles qui nécessitent un accès à une base de données : ```console django-admin check --database default --database other ``` Par défaut, ces contrôles ne sont pas effectués. #### `--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`](/fr/6.1/topics/settings/#envvar-DJANGO_SETTINGS_MODULE), soit en passant l’option `--settings`: ```console 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}` 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`](#django-admin-makemessages) en fichiers `.mo` utilisables par l’outil intégré `gettext`. Voir [Internationalisation et régionalisation](/fr/6.1/topics/i18n/). #### `--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 »)](https://www.gnu.org/software/gettext/manual/html_node/Fuzzy-Entries.html) dans les fichiers compilés. Exemple d’utilisation : ```console 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 ``` #### `--ignore PATTERN, -i PATTERN` Ignore répertoires correspondant au motif de type [`glob`](https://docs.python.org/3/library/glob.html#module-glob) donné. L’option peut être indiquée plusieurs fois pour des motifs différents. Exemple d’utilisation : ```console django-admin compilemessages --ignore=node_modules --ignore=outdated/*/locale ``` ### `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](/fr/6.1/topics/cache/) 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`](/fr/6.1/ref/settings/#std-setting-DATABASE-ENGINE), en respectant les paramètres de connexion définis dans les réglages [`USER`](/fr/6.1/ref/settings/#std-setting-USER), [`PASSWORD`](/fr/6.1/ref/settings/#std-setting-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 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'`. #### `-- ARGUMENTS` Tout paramètre suivant le séparateur `--` sera transmis au client de ligne de commande sous-jacent. Par exemple, avec PostgreSQL, il est possible d’utiliser l’option `-c` de la commande `psql` pour exécuter une requête SQL brute directement : ```console $ django-admin dbshell -- -c 'select current_user' current_user -------------- postgres (1 row) ``` *Windows* ```doscon ...\> django-admin dbshell -- -c 'select current_user' current_user -------------- postgres (1 row) ``` Avec MySQL/MariaDB, il est possible de faire de même avec l’option `-e` de la commande `mysql`: ```console $ django-admin dbshell -- -e "select user()" +----------------------+ | user() | +----------------------+ | djangonaut@localhost | +----------------------+ ``` *Windows* ```doscon ...\> django-admin dbshell -- -e "select user()" +----------------------+ | user() | +----------------------+ | djangonaut@localhost | +----------------------+ ``` > **Note** > > Il faut savoir que toutes les options de la clé [`OPTIONS`](/fr/6.1/ref/settings/#std-setting-OPTIONS) de la configuration de base de données dans [`DATABASES`](/fr/6.1/ref/settings/#std-setting-DATABASES) ne sont pas forcément transmises au client en ligne de commande, comme par exemple `'isolation_level'`. ### `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`](#cmdoption-diffsettings-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`](/fr/6.1/ref/settings/#std-setting-ROOT_URLCONF), donc [`ROOT_URLCONF`](/fr/6.1/ref/settings/#std-setting-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` 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. #### `--output {hash,unified}` Définit le format de sortie. Les valeurs disponibles sont `hash` et `unified`. `hash` est le mode par défaut qui produit le résultat décrit ci-dessus. `unified` affiche le résultat de manière semblable à `diff -u`. Les réglages par défaut sont préfixés par un signe moins, suivis par le réglage modifié préfixé par un signe plus. ### `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`](#django-admin-loaddata). Lorsque le résultat de `dumpdata` est enregistré dans un fichier, il peut servir d”[instantané](/fr/6.1/topics/db/fixtures/#fixtures-explanation) pour des [tests](/fr/6.1/topics/testing/tools/#topics-testing-fixtures) ou comme [données initiales](/fr/6.1/howto/initial-data/#initial-data-via-fixtures). 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é](/fr/6.1/topics/db/managers/#custom-managers) 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](/fr/6.1/topics/serialization/#serialization-formats). #### `--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, seul ce modèle sera exclu, et non pas 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`: ```console 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](/fr/6.1/topics/serialization/#topics-serialization-natural-keys) 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. #### Compression des instantanés Le fichier de sortie peut être compressé avec l’un des formats `bz2`, `gz`, `lzma` ou `xz` en terminant le nom de fichier indiqué par l’extension correspondante. Par exemple, pour produire des données dans un fichier JSON compressé : ```console django-admin dumpdata -o mydata.json.gz ``` ### `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`](#django-admin-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`](/fr/6.1/ref/settings/#std-setting-NAME) et affiche un module de modèle Django (un fichier `models.py`) vers la sortie standard. Vous pouvez choisir quelles tables ou vues inspecter en passant leur nom en paramètre. Si aucun paramètre n’est indiqué, les modèles pour les vues ne sont créés que si l’option [`--include-views`](#cmdoption-inspectdb-include-views) est indiquée. Des modèles pour les tables de partition sont créées avec PostgreSQL si l’option [`--include-partitions`](#cmdoption-inspectdb-include-partitions) est indiquée. 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. As you might expect, the created models will have an attribute for every field in the table. Note that `inspectdb` has a few special cases and limitations in its output: - 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é. Les champs reconnus peuvent dépendre des applications figurant dans [`INSTALLED_APPS`](/fr/6.1/ref/settings/#std-setting-INSTALLED_APPS). Par exemple, [`django.contrib.postgres`](/fr/6.1/ref/contrib/postgres/#module-django.contrib.postgres) ajoute la reconnaissance de plusieurs types de champs spécifiques à PostgreSQL. - 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. - Database defaults are not introspected and will be absent from the generated output. - Generated fields are mapped to their output field type. - Models that reference each other may not be in the correct order. - If models were managed by Django’s migration framework, Python-level field options that have no database-level representation will not be included. In particular, `Field.default` will not be included, and Python variants for `on_delete` are always emitted as `DO_NOTHING`. As such, after you run it, you’ll want to look over the generated models yourself to make customizations. This feature is meant as a shortcut, not as definitive model generation. 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`](/fr/6.1/ref/models/options/#django.db.models.Options.managed) pour lui donner la valeur `True` (ou carrément l’enlever, car `True` est sa valeur par défaut). #### Notes spécifiques à certaines bases de données ##### Oracle - Des modèles sont créés pour les vues matérialisées si l’option [`--include-views`](#cmdoption-inspectdb-include-views) est indiquée. ##### PostgreSQL - Des modèles sont créés pour les tables étrangères. - Des modèles sont créés pour les vues matérialisées si l’option [`--include-views`](#cmdoption-inspectdb-include-views) est indiquée. - Des modèles sont créés pour les tables de partition si l’option [`--include-partitions`](#cmdoption-inspectdb-include-partitions) est indiquée. #### `--database DATABASE` Indique la base de données qu’il s’agit d’examiner. La valeur par défaut est `default`. #### `--include-partitions` Si cette option est présente, des modèles sont aussi générés pour les partitions. Seule la prise en charge par PostgreSQL est implémentée. #### `--include-views` Si cette option est présente, des modèles sont aussi générés pour les vues de bases de données. ### `loaddata` #### `django-admin loaddata fixture [fixture ...]` Recherche et charge le contenu de [l’instantané](/fr/6.1/topics/db/fixtures/#fixtures-explanation) 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. #### `--format FORMAT` Indique le [format de sérialisation](/fr/6.1/topics/serialization/#serialization-formats) (e.g., `json` ou `xml`) pour les instantanés [lus à partir de l’entrée standard stdin](#loading-fixtures-stdin). #### `--exclude EXCLUDE, -e EXCLUDE` 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. #### Chargement d’instantanés à partir de `stdin` Vous pouvez utiliser un tiret comme nom d’instantané afin de charger les données depuis `sys.stdin`. Par exemple : ```console django-admin loaddata --format=json - ``` Lors de la lecture à partir de `stdin`, l’option [`--format`](#cmdoption-loaddata-format) est obligatoire pour indiquer le [format de sérialisation](/fr/6.1/topics/serialization/#serialization-formats) des données (par ex. `json` ou `xml`). Le chargement à partir de `stdin` est utile avec les redirections d’entrée/sortie standard. Par exemple : ```console django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod - ``` La commande [`dumpdata`](#django-admin-dumpdata) peut être utilisée pour générer le contenu donné à `loaddata`. > **See also** > > Pour plus de détails sur les instantanés, consultez la thématique [Instantanés](/fr/6.1/topics/db/fixtures/#fixtures-explanation). ### `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`](#django-admin-compilemessages) pour qu’ils soient utilisables par l’outil intégré `gettext`. Voir la [documentation d’internationalisation](/fr/6.1/topics/i18n/translation/#how-to-create-language-files) 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`](/fr/6.1/ref/settings/#std-setting-MEDIA_ROOT) et [`STATIC_ROOT`](/fr/6.1/ref/settings/#std-setting-STATIC_ROOT), ni inclure [`LOCALE_PATHS`](/fr/6.1/ref/settings/#std-setting-LOCALE_PATHS). #### `--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`](#cmdoption-makemessages-domain) vaut `djangojs`). Exemple d’utilisation : ```console django-admin makemessages --locale=de --extension xhtml ``` Séparez plusieurs extensions par une virgule ou utilisez plusieurs occurrences de `-e` ou `--extension`: ```console 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 : ```console 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 : ```console django-admin makemessages --locale=de --symlinks ``` #### `--ignore PATTERN, -i PATTERN` Ignore les fichiers ou répertoires correspondant au motif de type [`glob`](https://docs.python.org/3/library/glob.html#module-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 : ```console 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. #### `--add-location [{full,file,never}]` Contrôle les lignes de commentaires `#: nom_fichier:ligne` dans les fichiers de langue. Si l’option est : - `full` (par défaut) : les lignes contiennent à la fois les noms de fichiers et les numéros de lignes. - `file`: le numéro de ligne est omis. - `never`: les lignes sont supprimées (effet identique à [`--no-location`](#cmdoption-makemessages-no-location)). Nécessite `gettext` 0.19 ou plus récent. #### `--no-obsolete` Supprime les chaînes de messages obsolètes des fichiers `.po`. #### `--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. > **See also** > > Consultez [Personnalisation de la commande makemessages](/fr/6.1/topics/i18n/translation/#customizing-makemessages) pour des instructions sur la façon de personnaliser les mots-clés que [`makemessages`](#django-admin-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](/fr/6.1/topics/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. Le nom doit être un [identifiant](https://docs.python.org/3/reference/lexical_analysis.html#identifiers) Python valable. #### `--no-header` Génère des fichiers de migration sans l’en-tête d’horodatage et de version Django. #### `--check` Fait quitter `makemigrations` avec un statut différent de 0 lorsque des modifications de modèles sans migration correspondante sont détectés. Implique `--dry-run`. #### `--scriptable` Redirige les invites d’entrée et de sortie vers `stderr`, n’écrivant que les chemins des fichiers de migrations générés vers `stdout`. #### `--update` Fusionne les changements de modèles dans la dernière migration et optimise les opérations résultantes. La migration mise à jour possédera un nom généré automatiquement. Afin de préserver le nom précédent, il s’agit de l’indiquer avec `--name`. ### `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](/fr/6.1/topics/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> `: 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. Vous pouvez utiliser un préfixe du nom de migration, par ex. `0001`, pour autant qu’il soit unique pour le nom d’application indiqué. Utilisez le nom `zero` pour tout migrer à l’envers, c’est-à-dire défaire toutes les migrations d’une application. > **Warning** > > Lorsque vous défaites des migrations, toutes les migrations dépendantes seront aussi défaites, quel que soit le nom ``. Vuos pouvez utiliser `--plan` pour contrôler à l’avance quelles migrations seront défaites. #### `--database DATABASE` Désigne la base de données à migrer. La valeur par défaut est `'default'`. #### `--fake` Marque les migrations comme appliquées jusqu’à la migration cible (en suivant les règles ci-dessus), 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`](/fr/6.1/ref/migration-operations/#django.db.migrations.operations.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 que si vous savez pertinemment que le schéma actuel correspond bel et bien à ce qui est enregistré dans la migration initiale. #### `--plan` Montre les opérations de migration qui seront effectuées pour la commande `migrate` indiquée. #### `--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. #### `--check` Fait quitter `migrate` avec un statut différent de 0 lorsque des migrations non appliquées sont détectées. #### `--prune` Supprime les migrations non existantes de la table `django_migrations`. Ceci est utile lorsque les fichiers de migration remplacés par une migration de fusion ont été effacés. Voir [Fusion de migrations](/fr/6.1/topics/migrations/#migration-squashing) pour plus de détails. ### `optimizemigration` #### `django-admin optimizemigration app_label migration_name` Optimise les opérations de la migration nommée et écrase le fichier existant. Si la migration contient des fonctions qui doivent être recopiées manuellement, la commande crée un nouveau fichier de migration avec le suffixe `_optimized` qui est censé remplacer la migration nommée. #### `--check` Fait quitter `optimizemigration` avec un statut différent de 0 lorsque une migration peut être optimisée. ### `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`](/fr/6.1/ref/settings/#std-setting-WSGI_APPLICATION). > **Warning** > > N’UTILISEZ PAS CE SERVEUR DANS UN CONTEXTE DE PRODUCTION. > > Ce serveur de développement allégé n’a pas fait l’objet d’audits de sécurité ni de tests de performance, et n’est donc pas adéquat pour un fonctionnement en production. L’amélioration de ce serveur pour pouvoir gérer un environnement de production est en dehors des 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 ou MacOS et que vous installez à la fois [pywatchman](https://pypi.org/project/pywatchman/) et le service [Watchman](https://facebook.github.io/watchman/), 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). Cela améliore donc les performances pour les gros projets, ainsi qu’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 d’énergie. Django prend en charge `pywatchman` 1.2.0 ou plus récent. > **De gros dossiers avec beaucoup de fichiers peuvent causer des problèmes de performance** > > Lors de l’utilisation de Watchman sur un projet incluant de gros dossiers non Python comme par exemple `node_modules`, il est conseillé d’ignorer ces répertoires pour de meilleures performances. Consultez la [documentation de watchman](https://facebook.github.io/watchman/docs/config#ignore_dirs) pour plus d’informations sur ce sujet. > **Délai d’expiration Watchman** > > #### `DJANGO_WATCHMAN_TIMEOUT` > > > > > Le délai d’expiration par défaut du client `Watchman` est de 5 secondes. Vous pouvez le modifier en définissant la variable d’environnement [`DJANGO_WATCHMAN_TIMEOUT`](#envvar-DJANGO_WATCHMAN_TIMEOUT). 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`](#django-admin-check)). Si des erreurs sont détectées, celles-ci sont affichées dans la sortie standard. Vous pouvez utiliser l’option `--skip-checks` pour omettre l’exécution des contrôles système. Vous pouvez lancer autant de serveurs en parallèle que nécessaire, pour autant que ce soit sur des ports séparés, en exécutant 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`), `0` (raccourci pour `0.0.0.0`), `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](/fr/6.1/ref/contrib/staticfiles/) est activée (c’est le cas par défaut dans les nouveaux projets), la commande [`runserver`](#django-admin-runserver) est surchargée par sa propre commande [runserver](/fr/6.1/ref/contrib/staticfiles/#staticfiles-runserver). La journalisation de chaque requête et réponse du serveur est envoyée au journaliseur [django.server](/fr/6.1/ref/logging/#django-server-logger). #### `--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`. #### `DJANGO_RUNSERVER_HIDE_WARNING` Par défaut, un avertissement est affiché dans la console indiquant que `runserver` n’est pas conçu pour un environnement de production : ```text WARNING: This is a development server. Do not use it in a production setting. Use a production WSGI or ASGI server instead. For more information on production servers see: https://docs.djangoproject.com/en/|version|/howto/deployment/ ``` Définissez cette variable d’environnement à `"true"` pour masquer cet avertissement. #### Exemples d’utilisation de différents ports et adresses Port 8000 sur l’adresse IP `127.0.0.1`: ```console django-admin runserver ``` Port 8000 sur l’adresse IP `1.2.3.4`: ```console django-admin runserver 1.2.3.4:8000 ``` Port 7000 sur l’adresse IP `127.0.0.1`: ```console django-admin runserver 7000 ``` Port 7000 sur l’adresse IP `1.2.3.4`: ```console django-admin runserver 1.2.3.4:7000 ``` Port 8000 sur l’adresse IPv6 `::1`: ```console django-admin runserver -6 ``` Port 7000 sur l’adresse IPv6 `::1`: ```console django-admin runserver -6 7000 ``` Port 7000 sur l’adresse IPv6 `2001:0db8:1234:5678::9`: ```console django-admin runserver [2001:0db8:1234:5678::9]:7000 ``` Port 8000 sur l’adresse IPv4 de l’hôte `localhost`: ```console django-admin runserver localhost:8000 ``` Port 8000 sur l’adresse IPv6 de l’hôte `localhost`: ```console 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`](/fr/6.1/ref/settings/#std-setting-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)](/fr/6.1/howto/static-files/). #### Service avec ASGI en développement La commande `runserver` de Django fournit un serveur WSGI. Afin de tourner sous ASGI, il est nécessaire d’utiliser un [serveur ASGI](/fr/6.1/howto/deployment/asgi/). Le projet Daphne de Django fournit [Intégration avec runserver](/fr/6.1/howto/deployment/asgi/daphne/#daphne-runserver) qu’il est possible d’utiliser pour cela. ### `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 : ```console django-admin sendtestemail foo@example.com bar@example.com ``` The following options may be used in any combination with each other and with recipient email arguments. #### `--using ALIAS` > **New in Django 6.1** Specifies the [`MAILERS`](/fr/6.1/ref/settings/#std-setting-MAILERS) alias to use for sending the test email to the recipients given as arguments. Defaults to the `"default"` mailer. #### `--managers` Envoie le courriel aux adresses électroniques figurant dans [`MANAGERS`](/fr/6.1/ref/settings/#std-setting-MANAGERS) avec [`mail_managers()`](/fr/6.1/topics/email/#django.core.mail.mail_managers). #### `--admins` Envoie le courriel aux adresses électroniques figurant dans [`ADMINS`](/fr/6.1/ref/settings/#std-setting-ADMINS) avec [`mail_admins()`](/fr/6.1/topics/email/#django.core.mail.mail_admins). ### `shell` #### `django-admin shell` Lance l’interpréteur interactif Python. Tous les modèles de toutes les applications installées sont automatiquement importées dans l’environnement du shell. Priorité est donnée aux modèles des applications apparaissant en premier dans [`INSTALLED_APPS`](/fr/6.1/ref/settings/#std-setting-INSTALLED_APPS). Les utilitaires courants suivants sont aussi importés : ``` from django.db import connection, reset_queries, models from django.conf import settings from django.utils import timezone ``` Dans le cas d’une `--verbosity` de 2 ou plus, une liste des objets importés automatiquement est affichée. Pour complètement désactiver les importations automatiques, indiquez l’option `--no-imports`. Consultez le guide sur la [personnalisation de ce comportement](/fr/6.1/howto/custom-shell/#customizing-shell-auto-imports) pour ajouter ou enlever des importations automatiques. > **Changed in Django 6.0** > > Les importations automatiques d’utilitaires communs, tels que `django.conf.settings`, ont été ajoutées. #### `--interface {ipython,bpython,python}, -i {ipython,bpython,python}` Indique le shell à utiliser. Par défaut, Django utilise [IPython](https://ipython.org/) ou [bpython](https://bpython-interpreter.org/) s’ils sont installés. Si les deux sont installés, vous pouvez indiquer l’interpréteur souhaité comme ceci : IPython : ```console django-admin shell -i ipython ``` bpython : ```console 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 : ```console django-admin shell -i python ``` #### `--no-startup` 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`](https://docs.python.org/3/using/cmdline.html#envvar-PYTHONSTARTUP) ou le script `~/.pythonrc.py`. #### `--no-imports` Désactive l’importation automatique des modèles de [`INSTALLED_APPS`](/fr/6.1/ref/settings/#std-setting-INSTALLED_APPS). #### `--command COMMAND, -c COMMAND` Permet de transmettre une commande sous forme de texte à exécuter par Django, comme ceci : ```console 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 : ```console $ django-admin shell < import django > print(django.__version__) > EOF ``` Avec Windows, REPL est affiché en raison des limites d’implémentation de [`select.select()`](https://docs.python.org/3/library/select.html#select.select) sur cette plateforme. ### `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). Avec une `--verbosity` de 2 ou plus, les dates/heures d’application sont aussi montrées. 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. #### `--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`](#django-admin-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](/fr/6.1/topics/migrations/#migration-squashing). 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`](/fr/6.1/ref/migration-operations/#django.db.migrations.operations.RunPython) et [`django.db.migrations.operations.RunSQL`](/fr/6.1/ref/migration-operations/#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. #### `--squashed-name SQUASHED_NAME` Définit le nom de la migration fusionnée. Sans cela, le nom automatique se base sur les première et dernière migrations, avec `_squashed_` entre deux. #### `--no-header` Génère un fichier de migration fusionné sans l’en-tête d’horodatage et de version Django. ### `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 [nouveau répertoire](https://github.com/django/django/blob/stable/6.1.x/django/conf/app_template) contient un fichier `models.py` ainsi que d’autres fichiers modèles d’application. Si seul le nom d’application est indiqué, le répertoire de l’application sera créé dans le répertoire de travail actuel. Si une destination facultative est indiquée, Django va l’utiliser. Si le répertoire avec le nom indiqué n’existe pas il sera créé. Vous pouvez utiliser « . » pour signifier le répertoire de travail actuel. > **Changed in Django 6.0** > > La création automatique du répertoire de destination a été ajoutée. Par exemple : ```console django-admin startapp myapp /Users/jezdez/Code/myapp ``` #### `--template TEMPLATE` Fournit le chemin vers un répertoire contenant un modèle d’application personnalisé, un chemin vers une archive non compressée (`.tar`) ou une archive compressée (`.tar.gz`, `.tar.bz2`, `.tar.xz`, `.tar.lzma`, `.tgz`, `.tbz2`, `.txz`, `.tlz`, `.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`: ```console 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 : ```console django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/main.zip myapp ``` > **Warning** > > Les modèles indiqués via `--template` sont utilisés tels quels. Les modèles malveillants ou mal rédigés peuvent introduire des faiblesses de sécurité ou des comportements inattendus. Les archives compressées peuvent aussi consommer des ressources excessives durant leur extraction, pouvant être une cause potentielle de plantages ou d’indisponibilités. > > Le contenu des modèles devrait être soigneusement inspecté avant leur utilisation. #### `--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. #### `--exclude DIRECTORIES, -x DIRECTORIES` Indique quels répertoires dans le modèle d’application doivent être exclus, en plus de `.git` and `__pycache__`. Si cette option n’est pas donnée, les répertoires nommés `__pycache__` ou commençant par un `.` seront exclus. The template context (see [`Context`](/fr/6.1/ref/templates/api/#django.template.Context)) used for all matching files is: - 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'` - `django_version` – la version de Django, par ex. `'2.0.3'` > **Warning** > > 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`](/fr/6.1/ref/templates/builtins/#std-templatetag-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`. > **Warning** > > Le contenu de modèles d’applications (ou de projets) personnalisés devrait toujours être examiné soigneusement avant utilisation : de tels modèles définissent du code qui sera intégré à votre projet, ce qui signifie que vous devez faire confiance à ce code tout comme le vôtre ou celui d’une application tierce que vous installez. De plus, même le simple rendu des gabarits va en pratique exécuter du code qui a été fourni comme entrée de la commande d’administration. Le langage de gabarit de Django peut fournir un accès étendu au système, il faut donc s’assurer que tout gabarit personnalisé que vous utilisez soit digne de confiance. ### `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](https://github.com/django/django/blob/stable/6.1.x/django/conf/project_template) contient `manage.py` est un paquet de projet (contenant `settings.py` et d’autres fichiers). Si seul le nom de projet est fourni, le répertoire de projet et le paquet de projet seront tous deux nommés `` et le répertoire du projet sera créé dans le répertoire de travail actuel. Si une destination facultative est indiquée, Django va l’utiliser comme répertoire de projet, et crée `manage.py` ainsi que le paquet de projet à l’intérieur. Si le répertoire avec le nom indiqué n’existe pas, il sera créé. Utilisez « . » pour signifier le répertoire de travail actuel. > **Changed in Django 6.0** > > La création automatique du répertoire de destination a été ajoutée. Par exemple : ```console django-admin startproject myproject /Users/jezdez/Code/myproject_repo ``` #### `--template TEMPLATE` Indique un répertoire, une chemin de fichier ou une URL d’un modèle de projet personnalisé. Lisez la documentation de l’option [`startapp --template`](#cmdoption-startapp-template) pour des exemples d’utilisation. Les mêmes **considérations de sécurité** décrites pour les modèles `startapp` s’appliquent ici : les modèles malveillants ou mal rédigés peuvent introduire des faiblesses de sécurité ou consommer des ressources excessives. Leur contenu devrait être soigneusement inspecté avant leur 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. #### `--exclude DIRECTORIES, -x DIRECTORIES` Indique quels répertoires dans le modèle de projet doivent être exclus, en plus de `.git` and `__pycache__`. Si cette option n’est pas donnée, les répertoires nommés `__pycache__` ou commençant par un `.` seront exclus. The template context (see [`Context`](/fr/6.1/ref/templates/api/#django.template.Context)) used is: - 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`](/fr/6.1/ref/settings/#std-setting-SECRET_KEY) - `docs_version` – la version de la documentation : `'dev'` ou `'1.x'` - `django_version` – la version de Django, par ex. `'2.0.3'` Veuillez consultez également l’[avertissement concernant le rendu](#render-warning) et [l’avertissement de sûreté du code](#trusted-code-warning) mentionné pour la commande [`startapp`](#django-admin-startapp). ### `test` #### `django-admin test [test_label [test_label ...]]` Lance les tests de toutes les applications installées. Voir [Les tests dans Django](/fr/6.1/topics/testing/) 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`](/fr/6.1/ref/settings/#std-setting-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`](#cmdoption-test-testrunner) indiqué. Ces options sont celles du lanceur de tests par défaut : [`DiscoverRunner`](/fr/6.1/topics/testing/advanced/#django.test.runner.DiscoverRunner). #### `--keepdb` 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. Pour autant que le réglage de test [`MIGRATE`](/fr/6.1/ref/settings/#std-setting-TEST_MIGRATE) ne soit pas `False`, toute migration non appliquée sera aussi appliquée à la base de données de test avant de lancer la suite de tests. #### `--shuffle [SEED]` Rend aléatoire l’ordre des tests avant leur exécution. Ceci peut aider à détecter des tests qui ne sont pas proprement isolés. L’ordre des tests généré par cette option est une fonction déterministe du facteur nombre entier donné. Lorsqu’aucun facteur n’est donné, celui-ci est choisi au hasard et affiché dans la console. Pour répéter un ordre de test spécifique, passez un facteur. Les ordres des tests générés par cette option préservent la [garantie sur l’ordre des tests](/fr/6.1/topics/testing/overview/#order-of-tests) de Django. Ils conservent aussi le groupement des tests par classe de test. L’ordre aléatoire possède aussi une propriété de cohérence spéciale et bien utile lorsqu’on s’attaque à des problèmes d’isolation de tests. C’est-à-dire que pour un facteur donné et lors de l’exécution d’un sous-ensemble de tests, le nouvel ordre (aléatoire) est le même que précédemment mais restreint au plus petit sous-ensemble. De même, si on ajoute des tests en conservant le même facteur, l’ordre des premiers tests est toujours le même que l’ordre initial. #### `--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](/fr/6.1/topics/testing/overview/#order-of-tests) est conservé lors de l’utilisation de cette option. Cette option peut être utilisée de concert avec `--shuffle` afin d’inverser l’ordre correspondant à un facteur particulier. #### `--debug-mode` Définit le réglage [`DEBUG`](/fr/6.1/ref/settings/#std-setting-DEBUG) à `True` avant d’exécuter les tests. Cela peut aider à investiguer les échecs de tests. #### `--debug-sql, -d` Active la [journalisation SQL](/fr/6.1/ref/logging/#django-db-logger) des tests qui échouent. Si `--verbosity` vaut `2`, les requêtes dans les tests qui réussissent sont aussi affichées. #### `--parallel [N]` #### `DJANGO_TEST_PROCESSES` 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. En indiquant `--parallel` sans fournir de valeur ou avec la valeur `auto`, exécute un processus de tests par cœur en fonction de [`multiprocessing.cpu_count()`](https://docs.python.org/3/library/multiprocessing.html#multiprocessing.cpu_count). Vous pouvez forcer le nombre de processus souhaité en indiquant un nombre à l’option, par ex. `--parallel=4`, ou en définissant la variable d’environnement [`DJANGO_TEST_PROCESSES`](#envvar-DJANGO_TEST_PROCESSES). Django distribue les cas de test (sous-classes de [`unittest.TestCase`](https://docs.python.org/3/library/unittest.html#unittest.TestCase)) à des sous-processus. S’il y a moins de classes 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érentes classes de cas de test n’accèdent pas aux mêmes ressources. Par exemple, les classes de cas de test qui touchent au système de fichiers devraient créer un répertoire temporaire pour leur propre usage. > **Note** > > Si vous avez des classes de tests qui ne peuvent pas fonctionner en parallèle, vous pouvez utiliser `SerializeMixin` pour les exécuter de manière séquentielle. Voir [Exécution séquentielle des classes de tests](/fr/6.1/topics/testing/advanced/#topics-testing-enforce-run-sequentially). Cette option nécessite le paquet externe `tblib` pour afficher correctement les piles d’appels : ```console $ python -m 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`](https://docs.python.org/3/library/pdb.html#module-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`. > **Warning** > > 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?](https://docs.python.org/3/library/pickle.html#pickle-picklable) pour plus de détails. #### `--tag TAGS` N’exécute que les tests [marqués avec les étiquettes mentionnées](/fr/6.1/topics/testing/tools/#topics-tagging-tests). Plusieurs occurrences sont possibles et la combinaison est possible avec [`test --exclude-tag`](#cmdoption-test-exclude-tag). Les tests dont le chargement échoue sont toujours considérés comme inclus. #### `--exclude-tag EXCLUDE_TAGS` Exclut les tests [marqués avec les étiquettes mentionnées](/fr/6.1/topics/testing/tools/#topics-tagging-tests). Plusieurs occurrences sont possibles et la combinaison est possible avec [`test --tag`](#cmdoption-test-tag). #### `-k TEST_NAME_PATTERNS` Lance les méthodes et classes de test correspondant aux motifs de noms de tests, sur le même principe que [`unittest's -k option`](https://docs.python.org/3/library/unittest.html#cmdoption-unittest-k). Peut être indiquée plusieurs fois. #### `--pdb` Déclenche un débogueur `pdb` à chaque erreur ou échec de test. S’il est installé, c’est `ipdb` qui est lancé à la place. #### `--buffer, -b` Élimine la sortie (stdout\` et `stderr`) pour les tests qui réussissent, de la même manière que l’[`option --buffer de unittest`](https://docs.python.org/3/library/unittest.html#cmdoption-unittest-b). #### `--no-faulthandler` Django appelle automatiquement [`faulthandler.enable()`](https://docs.python.org/3/library/faulthandler.html#faulthandler.enable) au lancement des tests, ce qui lui permet d’afficher une trace d’erreur dans le cas où l’interpréteur plante. Passez `--no-faulthandler` pour désactiver ce comportement. #### `--timing` Ajoute les mesures temporelles des tests, y compris la mise en place de la base de données et le temps total d’exécution. #### `--durations N` Affiche les N cas de test les plus lents (N=0 pour tous). ### `testserver` #### `django-admin testserver [fixture [fixture ...]]` Lance un serveur de développement Django (comme avec [`runserver`](#django-admin-runserver)) en utilisant les données des instantanés indiqués. Par exemple, cette commande : ```console 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](/fr/6.1/topics/testing/overview/#the-test-database). 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`](#django-admin-loaddata)). 3. Lancement du serveur de développement de Django (comme avec [`runserver`](#django-admin-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](/fr/6.1/topics/testing/overview/) 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é](/fr/6.1/topics/db/fixtures/#fixtures-explanation) (par la commande [`dumpdata`](#django-admin-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`](#django-admin-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`](#django-admin-runserver). Exemples : Pour lancer le serveur de test sur le port 7000 avec les données `fixture1` et `fixture2`: ```console 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`: ```console 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](/fr/6.1/howto/custom-management-commands/) a été [`activée`](/fr/6.1/ref/settings/#std-setting-INSTALLED_APPS). Cette section les présente de manière groupée par application. ### `django.contrib.auth` #### `changepassword` #### `django-admin changepassword []` Cette commande n’est disponible que si le [système d’authentification](/fr/6.1/topics/auth/) 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 : ```console django-admin changepassword ringo ``` #### `createsuperuser` #### `django-admin createsuperuser` #### `DJANGO_SUPERUSER_PASSWORD` Cette commande n’est disponible que si le [système d’authentification](/fr/6.1/topics/auth/) 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, vous pouvez indiquer un mot de passe en définissant la variable d’environnement [`DJANGO_SUPERUSER_PASSWORD`](#envvar-DJANGO_SUPERUSER_PASSWORD). Sinon, 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. En mode non interactif, les champs [`USERNAME_FIELD`](/fr/6.1/topics/auth/customizing/#django.contrib.auth.models.CustomUser.USERNAME_FIELD) et obligatoires (énumérés dans [`REQUIRED_FIELDS`](/fr/6.1/topics/auth/customizing/#django.contrib.auth.models.CustomUser.REQUIRED_FIELDS)) se replient sur les valeurs de variables d’environnement `DJANGO_SUPERUSER_` quand elles ne figurent pas dans les paramètres de ligne de commande. Par exemple, pour fournir une valeur pour le champ `email`, vous pouvez définir une variable d’environnement `DJANGO_SUPERUSER_EMAIL`. #### `--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 1. #### `--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`](/fr/6.1/topics/auth/customizing/#django.contrib.auth.models.CustomUser.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` Cette commande n’est disponible que si l’[application « contenttypes »](/fr/6.1/ref/contrib/contenttypes/) ([`django.contrib.contenttypes`](/fr/6.1/ref/contrib/contenttypes/#module-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`. #### `--include-stale-apps` Supprime les types de contenus périmés, y compris ceux des applications précédemment installées qui ont été supprimées de [`INSTALLED_APPS`](/fr/6.1/ref/settings/#std-setting-INSTALLED_APPS). La valeur est `False` par défaut. ### `django.contrib.gis` #### `ogrinspect` Cette commande n’est disponible que si [GeoDjango](/fr/6.1/ref/contrib/gis/) (`django.contrib.gis`) est installé. Veuillez vous référer à sa [`description`](/fr/6.1/ref/contrib/gis/commands/#django-admin-ogrinspect) 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.staticfiles` #### `collectstatic` Cette commande n’est disponible que si l’[application des fichiers statiques](/fr/6.1/howto/static-files/) (`django.contrib.staticfiles`) est installée. Veuillez vous référer à sa [`description`](/fr/6.1/ref/contrib/staticfiles/#django-admin-collectstatic) dans la documentation des [fichiers statiques](/fr/6.1/ref/contrib/staticfiles/). #### `findstatic` Cette commande n’est disponible que si l’[application des fichiers statiques](/fr/6.1/howto/static-files/) (`django.contrib.staticfiles`) est installée. Veuillez vous référer à sa [`description`](/fr/6.1/ref/contrib/staticfiles/#django-admin-findstatic) dans la documentation des [fichiers statiques](/fr/6.1/ref/contrib/staticfiles/). ## Options par défaut Même si certaines commandes définissent leurs propres options personnalisées, chaque commande accepte les options suivantes par défaut : #### `--pythonpath PYTHONPATH` Ajoute le chemin de système de fichier indiqué à l’attribut de module [`sys.path`](https://docs.python.org/3/library/sys.html#sys.path) de Python. Quand cette option n’est pas renseignée, `django-admin` utilise la variable d’environnement [`PYTHONPATH`](https://docs.python.org/3/using/cmdline.html#envvar-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 : ```console 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`](/fr/6.1/topics/settings/#envvar-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 : ```console django-admin migrate --settings=mysite.settings ``` #### `--traceback` Affiche une trace de pile d’appels complète lorsqu’une exception [`CommandError`](/fr/6.1/howto/custom-management-commands/#django.core.management.CommandError) apparaît. Par défaut, `django-admin` affiche un message d’erreur chaque fois qu’une erreur `CommandError` se produit, et une trace de pile d’appels complète pour toute autre exception. Cette option est ignorée par [`runserver`](#django-admin-runserver). Exemple d’utilisation : ```console 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. Cette option est ignorée par [`runserver`](#django-admin-runserver). Exemple d’utilisation : ```console 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 : ```console django-admin runserver --no-color ``` #### `--force-color` Force la coloration du résultat de la commande dans le cas où elle aurait été désactivée comme discuté dans [Syntaxe colorée](#syntax-coloring). Par exemple, il peut être souhaité de rediriger le résultat coloré vers une autre commande. #### `--skip-checks` Omet les vérifications système avant de lancer la commande. Cette option n’est disponible que si l’attribut de commande [`requires_system_checks`](/fr/6.1/howto/custom-management-commands/#django.core.management.BaseCommand.requires_system_checks) n’est pas une liste ou un tuple vide. Exemple d’utilisation : ```console django-admin migrate --skip-checks ``` ## Options complémentaires ### Syntaxe colorée #### `DJANGO_COLORS` 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, sauf si l’option [`--force-color`](#cmdoption-force-color) est indiquée. #### Prise en charge avec Windows Avec Windows 10, l’application [Windows Terminal](https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701), [VS Code](https://code.visualstudio.com) et PowerShell (lorsque le traitement de terminal virtuel est activé) autorisent les contenus colorés et sont pris en charge par défaut. Avec Windows, l’ancienne console native `cmd.exe` ne prend pas en charge les séquences d’échappement ANSI, ce qui fait que le résultat n’est pas coloré. Dans ce cas, une des deux bibliothèques tierces suivantes est nécessaire : - Installez [colorama](https://pypi.org/project/colorama/), un paquet Python qui traduit les codes couleur ANSI en appels d’API Windows. Les commandes Django vont détecter sa présence et l’utiliser pour produire des sorties colorées comme pour les plates-formes de type Unix. `colorama` peut être installé avec pip : ```doscon ...\> py -m pip install "colorama >= 0.4.6" ``` - Installez [ANSICON](http://adoxa.altervista.org/ansicon/), un outil externe qui permet à `cmd.exe` de gérer les codes couleur ANSI. Les commandes Django vont détecter sa présence et l’utiliser pour produire des sorties colorées comme pour les plates-formes de type Unix. D’autre environnements de terminaux sous Windows qui prennent en charge la coloration mais qui ne sont pas détectés automatiquement comme pris en charge par Django peuvent simuler l’installation d”`ANSICON` en définissant la variable d’environnement appropriée, `ANSICON="on"`. #### Couleurs personnalisées 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`](#envvar-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 : ```shell 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 : ```shell 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 : ```shell 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](https://github.com/django/django/blob/stable/6.1.x/extras/django_bash_completion) de la distribution source de 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](/fr/6.1/howto/custom-management-commands/) pour savoir comment ajouter des actions personnalisées. ### Mise en forme par Black Les fichiers Python créés par [`startproject`](#django-admin-startproject), [`startapp`](#django-admin-startapp), [`optimizemigration`](#django-admin-optimizemigration), [`makemigrations`](#django-admin-makemigrations) et [`squashmigrations`](#django-admin-squashmigrations) sont mis en forme en utilisant la commande `black` si elle est présente dans votre chemin `PATH`. Si `black` est installé globalement mais que vous ne souhaitez pas l’utiliser pour le projet actuel, vous pouvez définir le chemin `PATH` explicitement : ```shell PATH=path/to/venv/bin django-admin makemigrations ``` Pour les commandes utilisant `stdout`, vous pouvez faire suivre la sortie vers `black` si nécessaire : ```shell django-admin inspectdb | black - ``` # 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. ## 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", "w") as f: management.call_command("dumpdata", stdout=f) ```