============================= django-admin.py et manage.py ============================= ``django-admin.py`` est l'utilitaire en ligne de commande de Django pour les tâches administratives. Ce document précise toutes ses possibilités. Un autre utilitaire, ``manage.py`` est de plus créé automatiquement dans chaque projet Django. ``manage.py`` encapsule ``django-admin.py`` et fait deux choses pour vous avant de passer la main à ``django-admin.py``: * Il ajoute le chemin de votre projet à ``sys.path``. * Il renseigne la variable d'environnement ``DJANGO_SETTINGS_MODULE``, qui pointe vers le fichier ``settings.py`` de votre projet. Le script ``django-admin.py`` devrait se trouver dans le chemin de recherche de votre système si vous avez installé Django avec l'utilitaire ``setup.py``. S'il n'y est pas, vous pouvez le trouver dans ``site-packages/django/bin`` dans votre installation Python. Vous devriez peut-être le lier symboliquement dans un emplacement connu de votre chemin de recherche, comme par exemple ``/usr/local/bin``. Windows ne possède pas de fonctionnalité de lien symbolique. Si vous utilisez Windows, vous pouvez copier ``django-admin.py`` quelque part dans votre chemin de recherche, ou éditer le réglage ``PATH`` (sous ``Panneau de configuration - Système - Avancé - Environnement...``) pour qu'il pointe également vers l'endroit où est installé ``django-admin.py``. En général, quand on travaille sur un seul projet Django, il est plus facile d'utiliser ``manage.py``. Utilisez ``django-admin.py`` avec ``DJANGO_SETTINGS_MODULE`` ou l'option de ligne de commande ``--settings`` si vous avez besoin de passer rapidement d'un fichier de réglages Django à un autre. Utilisation =========== ``django-admin.py [options]`` ``manage.py [options]`` ``subcommand`` doit être une des sous-commandes décrites dans ce document. ``options``, qui est facultatif, doit être zéro ou plus des options décrites dans ce document. Obtenir de l'aide à l'exécution ------------------------------- Dans Django 0.96, lancez ``django-admin.py --help`` pour afficher un message d'aide qui inclut une liste résumée de toutes les sous-commandes et options disponibles. Dans la version de développement de Django, lancez ``django-admin.py help`` pour afficher une liste de toutes les sous-commandes disponibles. Lancez ``django-admin.py help `` pour afficher une description de la sous-commande donnée et une liste de ses options. Noms des applications --------------------- Beaucoup de sous-commandes prennent une liste de ``noms d'applications``. Un "nom d'application" est le nom de base du paquet contenant vos modèles. Par example, si votre ``INSTALLED_APPS`` contient la chaîne ``mysite.blog``, le nom de l'application est ``blog``. Déterminer le numéro de version ------------------------------- Exécutez ``django-admin.py --version`` pour affichier le nom de la version de Django courante. Exemples de retours:: 0.95 0.96 0.97-pre-SVN-6069 Sous-commandes disponibles ========================== cleanup ------- **Nouveau dans la version de développement de Django** Peut être utilisé comme un job cron ou directement pour nettoyer les données anciennes de la base de données (seulement les sessions expirées pour le moment). compilemessages --------------- **Nouveau dans la version de développement de Django** Compile les fichiers .po créés avec ``makemessages`` en fichiers .mo qui seront utilisés avec le support gettext inclus. Voir la `documentation i18n`_ pour plus d'informations. .. _documentation i18n: ../i18n/ --locale ~~~~~~~~ Utilisez l'option ``--locale`` ou ``-l`` pour spécifier la locale à compiler. Si cette valeur n'est pas précisée, toutes les locales sont compilées. Exemple:: django-admin.py compilemessages --locale=br_PT createcachetable --------------------------- Crée une table cache nommée ``nomtable`` utilisée par le backend de la base de données. Voir la `documentation du cache`_ pour plus d'informations. .. _documentation du cache: ../cache/ createsuperuser --------------- **Nouveau dans la version de développement de Django** Crée un compte de superutilisateur (un utilisateur qui possède toutes les permissions). C'est utile si vous devez créer un compte de superutilisateur d'origine mais que vous ne l'avez pas fait pendant ``syncdb``, ou si vous devez générer des comptes de superutilisateurs pour vos sites par programme. Quand elle est utilisée de façon interactive, cette commande demandera un mot de passe pour le nouveau compte superutilisateur. Quand elle est utilisée de façon non interactive, aucun mot de passe ne sera créé, et le superutilisateur ne pourra pas se connecter tant qu'un mot de passe n'aura pas été créé pour son compte. Le nom d'utilisateur et l'adresse email pour le nouveau compte peuvent être précisés en utilisant les arguments ``--username`` et ``--email`` en ligne de commande. Si l'un quelconque des deux n'est pas fourni, ``createsuperuser`` le demandera quand il est utilisé de façon interactive. Cette commande n'est disponible que si le `système d'authentification`_ de Django (``django.contrib.auth``) est installé. .. _système d'authentification: ../authentication/ dbshell ------- Lance le client en ligne de commande pour le moteur de base de données spécifié dans votre réglage ``DATABASE_ENGINE``, avec les paramètres de connexion spécifiés dans vos réglages ``DATABASE_USER``, ``DATABASE_PASSWORD``, etc. * Pour PostgreSQL, lance le client en ligne de commande ``psql``. * Pour MySQL, lance le client en ligne de commande ``mysql``. * Pour SQLite, lance le client en ligne de commande ``sqlite3``. Cette commande suppose que les programmes sont sur votre ``PATH``, de telle façon qu'un simple appel au nom du programme (``psql``, ``mysql``, ``sqlite3``) le trouvera à son emplacement exact. Il n'y a aucune façon de spécifier l'emplacement du programme manuellement. diffsettings ------------ Affiche les différences entre le fichier de réglages courants et les réglages par défaut de Django. Les réglages qui n'apparaissent pas par défault sont suivis de ``"###"``. Par exemple, les réglages par défaut ne précisent pas ``ROOT_URLCONF``, donc cette variable est suivie de ``"###"`` dans la sortie de ``diffsettings``. Les réglages par défaut de Django sont dans ``django/conf/global_settings.py``, au cas où vous auriez la curiosité de voir la liste complète. dumpdata -------------------------------------- Envoie vers la sortie standard toutes les données des bases de données associées aux applications passées en paramètre. Si aucun nom d'application n'est passé en paramètre, toutes les applications installées seront utilisées. La sortie de ``dumpdata`` peut être utilisée comme flux d'entrée pour ``loaddata``. Notez que ``dumpdata`` utilise le manager par défaut du modèle pour sélectionner les enregistrements à envoyer en sortie. Si vous utilisez un `manager spécifique`_ comme manager par défaut et qu'il filtre certains enregistrements, les objets ne seront pas tous envoyés en sortie. .. _manager spécifique: ../model-api/#custom-managers --exclude ~~~~~~~~~ **Nouveau dans la version de développement de Django** Exclure une application particulière de celles dont les données seront envoyées en sortie. Par exemple, pour exclure spécifiquement les données de l'application `auth`, vous feriez : :: django=admin.py dumpdata --exclude=auth Si vous voulez exclure les données de plusieurs applications, utilisez plusieurs directives ``exclude`` : :: django=admin.py dumpdata --exclude=auth --exclude=contenttype --format ~~~~~~~~ Par défaut, ``dumpdata`` formatera sa sortie en JSON, mais vous pouvez utiliser l'option ``--format`` pour spécifier un autre format. Les formats supportés actuellement sont listés dans `Formats de sérialisation`_. Exemple:: django-admin.py dumpdata --format=xml .. _Formats de sérialisation: ../serialization/#serialization-formats --indent ~~~~~~~~ Par défaut, ``dumpdata`` enverra toutes les données en une seule ligne. Ce n'est pas facile à lire pour les êtres humains, donc vous pouvez utiliser l'option ``--indent`` pour afficher la sortie avec le nombre d'espaces d'indentation précisés. Exemple:: django-admin.py dumpdata --indent=4 flush ----- Remet la base de donnée dans l'état où elle se trouvait juste avant que syncdb ne soit exécuté. Cela signifie que toutes les données seront supprimées de la base, tous les scripts de post-synchronisation seront réexécutés, et le jeu de données ``initial_data`` sera réinstallé. Le comportement de cette commande a changé dans la version de développement de Django. Auparavant, la commande vidait *toutes* les tables de la base de données, y compris celles dont Django n'avait pas connaissance (comme les tables qui n'étaient associées à aucun modèle et/ou n'étaient pas dans ``INSTALLED_APPS``). Maintenant, la commande ne vide que les tables qui sont représentées par des modèles Django et sont activées dans ``INSTALLED_APPS``. --noinput ~~~~~~~~~ Utilisez l'option ``--noinput`` pour supprimer toutes les demandes à l'utilisateur, comme les messages de confirmation du genre "Êtes vous certain ?". C'est utile si ``django-admin.py`` est exécuté par un script sans intervention humaine. --verbosity ~~~~~~~~~~~ Utilisez ``--verbosity`` pour augmenter la quantité d'information de notification et de déboguage que ``django-admin.py`` affichera sur la console. * ``0`` ne donnera aucun affichage. * ``1`` affichage normal (valeur par défaut). * ``2`` affichage bavard. Exemple:: django-admin.py flush --verbosity=2 inspectdb --------- Inspecte les tables de la base de données pointées par la variable ``DATABASE_NAME`` et envoie un module de modèles Django (un fichier ``models.py``) sur la sortie standard. Utilisez cette commande si vous avez une base de données existante dont vous souhaitez vous servir avec Django. Le script examinera la base de données et créera un modèle pour chaque table de celle-ci. Comme on peut s'y attendre, les modèles créés auront un attribut pour chaque champ de la table. Notez que ``inspectdb`` peut générer quelques cas particuliers dans les noms de champ en sortie : * Si ``inspectdb`` ne peut pas associer le type d'une colonne avec un type de champ dans le modèle, il utilisera ``TextField`` et insérera le commentaire ``'This field type is a guess.'`` à côté du champ dans le modèle généré. * Si le nom de colonne dans la base de données est un nom réservé en Python (comme ``'pass'``, ``'class'`` ou ``'for'``), ``inspectdb`` ajoutera ``_field`` au nom de l'attribut. Par exemple, si une table possède une colonne ``'for'``, le modèle généré aura un champ ``'for_field'``, et l'attribut ``db_column`` aura pour valeur ``'for'``. ``inspectdb`` insérera le commentaire ``'Field renamed because it was a Python reserved word.'`` à côté du champ. Cette fonction est conçue pour vous faire gagner du temps, certainement pas pour vous donner une version définitive de vos modèles. Après l'avoir utilisée, passez en revue les modèles générés pour les personnaliser. Vous devrez en particulier ré-ordonner les modèles de telle façon que ceux qui sont référencés par d'autres soient présentés dans l'ordre nécessaire. Les clés primaires sont repérées automatiquement pour PostgreSQL, MySQL et SQLite, et Django positionnera correctement l'attribut ``primary_key=True`` là où il est nécessaire. ``inspectdb`` fonctionne avec PostgreSQL, MySQL et SQLite. La détection des clés étrangères ne fonctionne qu'avec PostgreSQL et certains types de tables MySQL. loaddata ------------------------------ Cherche le jeu de données (fixture) indiqué et le charge dans la base de données. Un *jeu de données* est une collection de fichiers qui contiennent les données sérialisées d'une base de données. Chaque jeu de données possède un nom unique, et les fichiers qui le composent peuvent être répartis dans de nombreux répertoires et applications. Django cherche les jeux de données aux trois emplacements suivants : 1. Dans le répertoire ``fixtures`` de chaque application installée 2. Dans chaque répertoire listé dans la variable ``FIXTURE_DIRS`` 3. Dans le chemin indiqué en ligne de commande avec le jeu de données Django chargera dans la base de données tous les jeux de données qu'il trouvera dans chacun de ces emplacements. Si le jeu de données indiqué a une extension qui indique un format de stockage, seuls les jeux de ce format seront utilisés. Par exemple:: django-admin.py loaddata mydata.json ne chargera que les jeux de données appelés ``mydata`` et au format JSON. L'extension doit correspondre au nom répertorié d'un format de sérialisation (comme par exemple ``json`` ou ``xml``). Si vous omettez l'extension, Django cherchera le jeu de donnés dans tous les formats possibles. Par exemple:: django-admin.py loaddata mydata cherchera les jeux de données appelés ``mydata`` dans tous les formats possibles. Si un répertoire de jeux de données contient ``mydata.json``, ce jeu de données sera chargé comme un jeu au format JSON. Toutefois, si deux jeux de données avec le même nom mais un format différent sont rencontrés (par exemple, si ``mydata.json`` et ``mydata.xml`` sont dans le même répertoire), le chargement des jeux de données est abandonné, et toutes les données installées pendant cet appel à ``loaddata`` seront supprimées de la base de données. Les jeux de données indiqués en paramètres peuvent préciser un chemin. Les répertoires correspondant seront inclus dans la recherche. Par exemple:: django-admin.py loaddata foo/bar/mydata.json cherchera dans ``/fixtures/foo/bar/mydata.json`` pour toutes les applications installées, dans ``/foo/bar/mydata.json`` pour tous les répertoires listés dans ``FIXTURE_DIRS`` et essaiera enfin le chemin ``foo/bar/mydata.json``. Notez que l'ordre dans lequel les fichiers du jeu de données sont traités n'est pas défini. Cependant, les données du jeu sont installées en une seule transaction, ce qui permet aux données d'un jeu de référencer les données d'un autre jeu. Si l'interface de la base de données supporte les contraintes au niveau ligne, ces contraintes seront vérifiées en fin de transaction. .. admonition:: MySQL et les jeux de données Malheureusement, MySQL ne peut pas supporter complètement toutes les caractéristiques de jeux de données Django. Si vous utilisez des tables MyISAM, MySQL ne supporte pas les transactions ni les contraintes, donc vous n'aurez ni retour en arrière si de multiples fichiers de transaction sont trouvés, ni la validation des données du jeu. Si vous utilisez des tables InnoDB, vous ne pourrez pas avoir de références "en avant" (forward references) dans vos fichiers de données - MySQL ne fournit pas de mécanisme qui permette de retarder la vérification des contraintes sur les lignes jusqu'à ce qu'une transaction soit validée. --verbosity ~~~~~~~~~~~ Utilisez ``--verbosity`` pour augmenter la quantité d'information de notification et de déboguage que ``django-admin.py`` affichera sur la console. * ``0`` ne donnera aucun affichage. * ``1`` affichage normal (valeur par défaut). * ``2`` affichage bavard. Exemple:: django-admin.py loaddata --verbosity=2 makemessages ------------ **Nouveau dans la version de développement de Django** Parcourt l'ensemble de l'arbre des sources du répertoire courant, et récupère toutes les chaînes de caractères à traduire. Crée (ou met à jour) un fichier de messages dans le répertoire conf/locale (dans l'arbre des sources Django) ou locale (pour un projet ou une application). Une fois que vous aurez fait les changements nécessaires sur les fichiers de messages, vous devrez les compiler avec ``compilemessages`` pour les utiliser avec le support gettext inclus. Voir la `documentation i18n`_ pour plus d'informations. --all ~~~~~ Utilisez l'option ``-all`` ou ``-a`` pour mettre à jour les fichiers de messages pour toutes les langues disponibles. Exemple:: django-admin.py makemessages --all --extension ~~~~~~~~~~~ Utilisez l'option ``--extension`` ou ``-e`` pour spécifier une liste d'extensions de fichiers à examiner (la valeur par défaut est ".html"). Exemple:: django-admin.py makemessages --locale=de --extension xhtml Séparez des valeurs multiples par des virgules, ou utilisez -e ou --extension plusieurs fois : :: django-admin.py makemessages --locale=de --extension=html,txt --extension xml --locale ~~~~~~~~ Utilisez l'option ``--locale`` ou ``-l`` pour spécifier les locales à traiter. Exemple:: django-admin.py makemessages --locale=br_PT --domain ~~~~~~~~ Utilisez l'option ``--domain`` ou ``-d`` pour changer le domaine d'application des fichiers de messages. Actuellement, sont supportés : :: * ``django`` pour tous les fichiers ``*.py`` et ``*.html`` (valeur par défaut) * ``djangojs`` pour les fichiers ``*.js`` --verbosity ~~~~~~~~~~~ Utilisez ``--verbosity`` pour augmenter la quantité d'information de notification et de déboguage que ``django-admin.py`` affichera sur la console. * ``0`` ne donnera aucun affichage. * ``1`` affichage normal (valeur par défaut). * ``2`` affichage bavard. Exemple:: django-admin.py makemessages --verbosity=2 reset ----------------------------------- Exécute l'équivalent de ``sqlreset`` pour les applications données. --noinput ~~~~~~~~~ Utilisez l'option ``--noinput`` pour supprimer toutes les demandes à l'utilisateur, comme les messages de confirmation du genre "Êtes vous certain ?". C'est utile si ``django-admin.py`` est exécuté par un script sans intervention humaine. runfcgi [options] ----------------- Lance un ensemble de processus FastCGI utilisables avec tout serveur Web supportant ce protocole. Voir la `documentation de déploiement de FastCGI`_ pour plus d'informations. Le module Python FastCGI de `flup`_ est requis. .. _documentation de déploiement de FastCGI: ../fastcgi/ .. _flup: http://www.saddi.com/software/flup/ runserver [numéro de port (optionnel), ou ipaddr:port] ------------------------------------------------------ Démarre un serveur web de développement sur la machine locale. Par défaut, le serveur écoute le port 8000 sur l'adresse IP 127.0.0.1. Vous pouvez passer en paramètres une adresse IP et un numéro de port explicitement. Si vous lancez ce script en tant qu'utilisateur avec des privilèges normaux (recommandé), il est possible que vous n'ayez pas accès aux numéros de ports inférieurs à 1024, qui sont réservés au super-utilisateur (root). N'UTILISEZ PAS CE SERVEUR DANS UN ENVIRONNEMENT DE PRODUCTION. Il n'a pas été audité, ni pour la sécurité, ni pour les performances. (Et il ne le sera pas. Nous faisons des environnements de développement Web, pas des serveurs, et l'amélioration de ce serveur en vue de le rendre capable de supporter un environnement de production n'est pas dans les intentions ou la mission de Django.) Le serveur de développement recharge automatiquement le code Python à chaque requête. Vous n'avez pas besoin de redémarrer le serveur pour que les modifications du code soient prises en compte. Lorsque vous démarrez le serveur, et chaque fois que vous changez le code pendant que le serveur fonctionne, celui-ci validera tous les modèles installés. (Voir la commande ``validate`` ci-dessous). Si le validateur trouve des erreurs, il les enverra vers la sortie standard, mais il ne stoppera pas le serveur. Vous pouvez exécuter autant de serveurs que vous le voulez, du moment qu'ils écoutent des ports différents. Il suffit de lancer la commande ``django-admin.py runserver`` plus d'une fois. Notez que l'adresse IP utilisée par défaut, 127.0.0.1, n'est pas accessible par les autres machines de votre réseau. Pour rendre le serveur de développement accessible par les autres machines de votre réseau, utilisez l'adresse IP de la machine sur celui-ci (par exemple ``192.168.2.1``) ou ``0.0.0.0``. --adminmedia ~~~~~~~~~~~~ Utilisez l'option ``--adminmedia`` pour indique à Django où trouver les différents fichiers CSS et JavaScript nécessaires à son interface d'administration. En principe, le serveur de développement de Django récupère ces fichiers dans l'arbre des sources de Django automatiquement, mais vous aurez à utiliser cette option si vous voulez modifier ces fichiers pour votre site. Exemple:: django-admin.py runserver --adminmedia=/tmp/new-admin-style/ --noreload ~~~~~~~~~~ Utilisez l'option ``--noreload`` pour désactiver le rechargement automatique des sources. Cela signifie que les changements que vous faites au code Python ne seront *pas* pris en compte si le module Python concerné a déjà été chargé en mémoire. Exemple:: django-admin.py runserver --noreload Exemples d'usage sur différents ports et adresses: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Port 8000 sur l'adresse IP 127.0.0.1:: django-admin.py runserver 8000 Port 8000 sur l'adresse 1.2.3.4:: django-admin.py runserver 1.2.3.4:8000 Port 7000 sur l'adresse IP 127.0.0.1:: django-admin.py runserver 7000 Comment servir des fichiers statiques avec le serveur de développement ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Par défaut, le serveur de développement ne sert aucun fichier statique pour votre site (comme des fichiers CSS, des images, tout ce qui peut se trouver dans ``MEDIA_ROOT_URL``, etc.). Si vous voulez configurer Django pour qu'il serve des fichiers statiques, lisez la documentation `servir des fichiers statiques`_. .. _servir des fichiers statiques: ../static_files/ shell ----- Démarre l'interpréteur en mode interactif de Python. Django utilisera IPython_ s'il est installé. Si IPython est installé et que vous voulez utiliser l'interpréteur de base de Python, utilisez l'option ``--plain`` de cette façon:: django-admin.py shell --plain .. _IPython: http://ipython.scipy.org/ sql --------------------------------- Affiche les commandes SQL CREATE TABLE pour les applications indiquées. sqlall ------------------------------------ Affiche les commandes SQL CREATE TABLE et d'ajout de données initiales pour les applications indiquées. Voir la description de la commande ``sqlcustom`` ci-dessous pour savoir comment spécifier des données initiales. sqlclear -------------------------------------- Affiche les commandes SQL DROP TABLE pour les applications indiquées. sqlcustom --------------------------------------- Affiche les commandes SQL personnalisées pour les applications indiquées. Pour chaque modèle de chaque application spécifiée, cette commande recherche le fichier ``/sql/.sql``, où ```` est l'application donnée et ```` le nom du modèle en minuscules. Par exemple, si vous avez une application ``news`` qui inclut un modèle ``Article``, ``sqlcustom`` essaiera de lire un fichier ``news/sql/article.sql`` et l'ajoutera à la sortie de cette commande. Chaque fichier SQL, s'il existe, doit contenir du SQL valide. Les fichiers SQL sont directement passés à la base de données après que toutes les commandes de création de tables aient été exécutés. Utilisez ce lien avec SQL pour faire les modifications de tables ou les insertions de fonctions que vous souhaitez dans la base de données. Notez que l'ordre dans lequel les fichiers SQL sont traités n'est pas défini. sqlflush -------- Affiche les commandes SQL qui seraient exécutées par la commande `flush`_. sqlindexes ---------------------------------------- Affiche les commandes SQL CREATE INDEX pour les applications indiquées. sqlreset -------------------------------------- Affiche les commandes SQL DROP TABLE puis CREATE TABLE pour les applications indiquées. sqlsequencereset ---------------------------------------------- Affiche les commandes SQL pour réinitialiser les séquences PostgreSQL pour les applications indiquées. Voir http://simon.incutio.com/archive/2004/04/21/postgres pour de plus amples informations. startapp ---------------------- Crée un répertoire d'application Django pour l'application indiquée dans le répertoire courant. startproject --------------------- Crée un répertoire de projet Django pour le projet indiqué dans le répertoire courant. syncdb ------ Crée les tables de base de données pour toutes les applications listées dans ``INSTALLED_APPS`` dont les tables n'existent pas encore. Utilisez cette commande lorsque vous avez ajouté de nouvelles applications à votre projet et voulez les installer dans la base de données. Les applications livrées avec Django qui peuvent être dans ``INSTALLED_APPS`` par défaut sont concernées également. Lorsque vous commencez un nouveau projet, utilisez cette commande pour installer les applications par défaut. .. admonition:: Syncdb ne touchera pas aux tables existantes ``syncdb`` ne fera que créer les tables pour les modèles qui n'ont pas encore fait l'objet d'une installation. Elle n'émettra *jamais* de commande ``ALTER TABLE`` pour suivre les modifications faites à une classe de modèle après son installation. Les changements des classes de modèles et de schémas de bases de données ont souvent leur part d'ambiguïté, et, dans ce genre de cas, Django aurait à deviner les modifications correctes qu'il faut faire. Il existe un risque de perdre des données critiques dans ce cas. Si vous devez faire des modifications à un modèle et voulez altérer vous-même la table de base de données pour qu'elle suive ces modifications, utilisez la commande ``sql`` pour afficher la nouvelle structure SQL de la table et la comparer à l'existant afin de repérer les modifications. Si vous installez l'application ``django.contrib.auth``, ``syncdb`` vous proposera de créer un superutilisateur immédiatement. ``syncdb`` cherchera et installera également tout jeu de données nommé ``initial_data``. Voyez la documentation de ``loaddata`` pour les détails de la spécification des fichiers de jeux de données. --verbosity ~~~~~~~~~~~ Utilisez ``--verbosity`` pour augmenter la quantité d'information de notification et de déboguage que ``django-admin.py`` affichera sur la console. * ``0`` ne donnera aucun affichage. * ``1`` affichage normal (valeur par défaut). * ``2`` affichage bavard. Exemple:: django-admin.py syncdb --verbosity=2 --noinput ~~~~~~~~~ Utilisez l'option ``--noinput`` pour supprimer toutes les demandes à l'utilisateur, comme les messages de confirmation du genre "Êtes vous certain ?". C'est utile si ``django-admin.py`` est exécuté par un script sans intervention humaine. test ---- Exécute les tests pour tous les modèles installés. Voir `Tester les applications Django`_ pour plus d'informations. .. _Tester les applications Django: ../testing/ --noinput ~~~~~~~~~ Utilisez l'option ``--noinput`` pour supprimer toutes les demandes à l'utilisateur, comme les messages de confirmation du genre "Êtes vous certain ?". C'est utile si ``django-admin.py`` est exécuté par un script sans intervention humaine. --verbosity ~~~~~~~~~~~ Utilisez ``--verbosity`` pour augmenter la quantité d'information de notification et de déboguage que ``django-admin.py`` affichera sur la console. * ``0`` ne donnera aucun affichage. * ``1`` affichage normal (valeur par défaut). * ``2`` affichage bavard. Exemple:: django-admin.py test --verbosity=2 testserver -------------------------------- **Nouveau dans la version de développement de Django** Exécute le serveur de développement de Django (comme ``runserver``) en utilisant les jeux de données (``fixture``) indiqués. Par exemple, cette commande:: django-admin.py testserver mydata.json ... entraînerait les étapes suivantes : 1. Création d'une base de données de test, comme il est décrit dans `Tester les applications Django`_. 2. Enregistrement des données des jeux de données indiqués dans la base de données. (Pour plus d'informations sur les jeux de données, voir la documentation de ``loaddata`` ci-dessus.) 3. Exécution du serveur de développement de Django (comme ``runserver``) en utilisant cette base de données de test à la place de la base de production. C'est utile dans différents cadres : * Quand vous écrivez des `tests unitaires`_ sur la façon dont vos vues fonctionnent avec certains jeux de données, vous pouvez utiliser ``testserver`` pour interagir avec les vues dans un navigateur web, manuellement. * Supposons que vous développez une application Django et que vous avez une copie d'origine de votre base de données avec laquelle vous aimeriez travailler. Vous pouvez sauver votre base dans un jeu de données (en utilisant la commande ``dumpdata`` expliquée ci-dessus), puis utiliser ``testserver`` pour travailler sur votre application web avec ces données. De cette façon, vous avez la possibilité de modifier les données autant que vous le voulez en sachant que les modifications que vous faites ne touchent que la base de test, et donc que l'intégrité de la base originale est respectée. Notez que ce serveur ne détecte pas automatiquement les changements de votre code source Python (comme le fait ``runserver``). Toutefois, il détecte les changements dans les templates. .. _tests unitaires: ../testing/ --addrport [numéro de port ou ipaddr:port] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Utilisez ``--addrport`` pour spécifier un port et une adresse différents des valeurs par défaut de 127.0.0.1:8000. Ces valeurs ont exactement le même format et les mêmes fonctions que les arguments de la sous-commande ``runserver``. Exemples: Pour utiliser le serveur de test sur le port7000 avec les jeux de données ``fixture1`` et ``fixture2``:: django-admin.py testserver --addrport 7000 fixture1 fixture2 django-admin.py testserver fixture1 fixture2 --addrport 7000 (Les deux commandes ci-dessus sont équivalentes. Nous les montrons toutes les deux pour indiquer que le fait que les options viennent avant ou après les arguments de jeux de données est sans importance.) Pour l'exécuter sur 1.2.3.4:7000 avec le jeu de données ``test``:: django-admin.py testserver --addrport 1.2.3.4:7000 test --verbosity ~~~~~~~~~~~ Utilisez ``--verbosity`` pour augmenter la quantité d'information de notification et de déboguage que ``django-admin.py`` affichera sur la console. * ``0`` ne donnera aucun affichage. * ``1`` affichage normal (valeur par défaut). * ``2`` affichage bavard. Exemple:: django-admin.py testserver --verbosity=2 validate -------- Valide tous les modèles installés (en fonction de la variable ``INSTALLED_APPS``) et affiche les erreurs de validation sur la sortie standard. Options par défaut ================== Bien que certaines sous-commandes aient des options spécifiques, elles acceptent toutes les options qui suivent. --pythonpath ------------ Exemple:: django-admin.py syncdb --pythonpath='/home/djangoprojects/myproject' Ajoute le chemin système indiqué au `chemin de recherche d'import`_ Python. Si cette option n'est pas fournie, ``django-admin.py`` utilisera la valeur de la variable d'environnement ``PYTHONPATH``. Notez que cette option n'est pas nécessaire pour ``manage.py``, parce que ce script s'occupe du chemin de recherche Python pour vous. .. _chemin de recherche d'import: http://diveintopython.org/getting_to_know_python/everything_is_an_object.html --settings ---------- Exemple:: django-admin.py syncdb --settings=mysite.settins Spécifie de façon explicite le module de réglages (``settings``) à utiliser. Le module doit être indiqué en syntaxe Python, par exemple ``mysite.settings``. Si cette option n'est pas fournie, Django utilisera la valeur de la variable d'environnement ``DJANGO_SETTINGS_MODULE``. Notez que cette option n'est pas nécessaire avec ``manage.py``, parce qu'il utilise le ``settings.py`` du projet courant par défaut. --traceback ----------- Exemple:: django-admin.py syncdb --traceback Par défaut, ``django-admin.py`` ne donnera qu'un message simple en cas d'erreur. Si vous spécifiez ``--traceback``, ``django-admin.py`` donnera la trace de la pile complète d'erreurs si une exception est levée. Subtilités supplémentaires ========================== Coloration syntaxique --------------------- Les commandes ``django-admin.py`` et ``manage.py`` qui envoient du SQL sur la sortie standard utiliseront la coloration syntaxique si votre terminal supporte les codes de couleurs ANSI. Les codes de couleurs ne sont pas utilisés si la sortie est passée (par un tunnel) à un autre programme. Le complément de commandes Bash ------------------------------- Si vous utilisez l'interpréteur de commandes Bash, vous pouvez installer le script de complément de commandes (tab completion) pour Django. Il se trouve dans la distribution Django à l'emplacement ``extras/django_bash_completion``. Il permet le complément de commandes pour ``django-admin.py`` et ``manage.py``, et vous pourrez alors... * Entrer ``django-admin.py`` * Appuyer sur [TAB] pour voir toutes les options disponibles * Entrer ``sql``, puis [TAB], pour voir toutes les options qui commencent par ``sql``. Commandes personnalisées ======================== **Nouveau dans la version de développement de Django** Les applications peuvent enregistrer leurs propres actions avec ``manage.py``. Par exemple, vous pourriez vouloir ajouter une action ``manage.py`` pour une application Django que vous distribuez. Pour ce faire, ajoutez simplement un répertoire ``management/commands`` à votre application. Chaque module Python de ce répertoire sera automatiquement découvert et enregistré en tant que commande exécutable lorsque vous lancerez ``manage.py``:: blog/ __init__.py models.py management/ __init__.py commands/ __init__.py explode.py views.py Dans cet exemple, la commande ``explode`` sera disponible pour tous les projets qui possèdent l'application ``blog`` dans ``settings.INSTALLED_APPS``. Il n'y a qu'une seule contrainte sur le module ``explode.py`` -- il doit définir une classe appelée ``Command`` qui hérite de ``django.core.management.base.BaseCommand``. Pour plus de détails sur la façon de définir vos propres commandes, regardez le code de celles de ``django-admin.py``, dans ``/django/core/management/commands``.