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
adminindex <application application ...>
Affiche les fragments de codes du template de l'index de la page d'administration pour les applications passées en paramètre.
Utilisez les fragments de code du template de l'index de la page d'administration si vous voulez personnaliser l'apparence de votre page d'administration. Voir tutorial 2 pour des informations plus détaillées.
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.
--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.
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é.
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.
--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
--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 :
- Dans le répertoire fixtures de chaque application installée
- Dans chaque répertoire listé dans la variable FIXTURE_DIRS
- 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.
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
--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.
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.
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
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.
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.
--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 :
- Création d'une base de données de test, comme il est décrit dans Tester les applications Django.
- 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.)
- 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.
--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.
--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.