root/docs/trunk/django-admin.txt

=============================
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 <subcommand> [options]``

``manage.py <subcommand> [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 <subcommand>`` 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 <nomtable>
---------------------------

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

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

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 ``<application>/fixtures/foo/bar/mydata.json`` pour toutes les
applications installées, dans ``<dirname>/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 <application application ...>
-----------------------------------

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

Affiche les commandes SQL CREATE TABLE pour les applications indiquées.

sqlall <application application ...>
------------------------------------

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

Affiche les commandes SQL DROP TABLE pour les applications indiquées.

sqlcustom <application application ...>
---------------------------------------

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 ``<application>/sql/<modelname>.sql``, où ``<application>`` est
l'application donnée et ``<modelname>`` 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 <application application ...>
----------------------------------------

Affiche les commandes SQL CREATE INDEX pour les applications indiquées.

sqlreset <application application ...>
--------------------------------------

Affiche les commandes SQL DROP TABLE puis CREATE TABLE pour les applications
indiquées.

sqlsequencereset <application application ...>
----------------------------------------------

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

Crée un répertoire d'application Django pour l'application indiquée dans le
répertoire courant.

startproject <projet>
---------------------

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

**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``.