django-admin.py e manage.py¶

django-admin.py é o utilitário de linha de comando do Django para tarefas administrativas.

Este documento contempla tudo que ele pode fazer.

Além disso, manage.py é automaticamente criado em cada projeto Django. O manage.py é um wrapper simples em volta do django-admin.py que se preocupa com duas coisas por você antes de delegar tarefas ao django-admin.py:

Ele coloca o pacote do seu projeto no sys.path.
Ele define a variável de ambiente DJANGO_SETTINGS_MODULE que então aponta para o arquivo settings.py do seu projeto.

O script django-admin.py deve estar no path do seu sistema se você instalou o Django via o utilitário setup.py. Se não estiver no seu path, você pode encontrá-lo dentro da sua instalação Python em site-packages/django/bin. Considere criar um link simbólico para ele no path do seu sistema, como /usr/local/bin.

Para usuários Windows, que não possuem a funcionalidade de link simbólico disponível, você pode copiar o django-admin.py para um local existente em seu path ou editar as configurações de PATH (sob Configurações - Painel de Controle - Sistema - Avançado - Ambiente...) para apontar para o local instalado.

Geralmente, quando se trabalha com um único projeto Django, é mais fácil usar o manage.py. Usar o django-admin.py com DJANGO_SETTINGS_MODULE, ou a opção de linha de comando --settings, se você precisar trocar entre vários arquivos settings do Django.

Os exemplos de linha de comando de todo este documento usa o django-admin.py para ser consistente, mas qualquer exemplo pode usar o manage.py da mesma forma.

Uso¶

django-admin.py <subcommand> [options]
manage.py <subcommand> [options]

subcommand deve ser um dos subcomandos listados neste documento. options, que é opcional, deve ser zero ou mais das opções disponíveis para um dado subcomando.

Obtendo ajuda em tempo de execução¶

--help¶

Execute django-admin.py help para mostrar uma lista de todos os subcomandos disponíveis. Execute django-admin.py help <subcommand> para mostrar uma descrição do subcomando em questão e uma lista de suas opções disponíveis.

App names¶

Muitos subcomandos recebem uma lista de “app names”. Um “app name” é o nome básico do pacote contento seus models. Por exemplo, se sua INSTALLED_APPS contém a string 'mysite.blog', o app name é blog.

Determinando a versão¶

--version¶

Execute django-admin.py --version para mostra a versão atual do Django.

Exemplos de saídas:

95
96
97-pre-SVN-6069

Mostrando saída de debug¶

--verbosity <amount>¶

Use --verbosity para especificar o montante de notificações e informações de debug que django-admin.py deve imprimir no console.

0 significa nenhuma saída.
1 significa saída normal (padrão).
2 significa saída prolixa.

Subcomandos disponíveis¶

cleanup¶

Please, see the release notes

Pode ser executado como um cronjob ou diretamente para limpar dados antigos do banco de dados (somente sessões expiradas até o momento).

compilemessages¶

Antes do 1.0 este era o comando “bin/compile-messages.py”.

Compila arquivos .po criados com makemessages para arquivos .mo para uso com o suporte embutido ao gettext. Veja Internacionalização.

–locale¶

Use as opções --locale ou -l para especificar o locale a ser processado. Se você não especificá-lo, todos os locales são processados.

Exemplo de uso:

django-admin.py compilemessages --locale=pt_BR

createcachetable¶

django-admin.py createcachetable <tablename>¶

Cria uma tabela de cache com o nome tablename para uso com o backend de cache em banco de dados.

createsuperuser¶

django-admin.py createsuperuser¶

Please, see the release notes

Cria uma conta de superusuário (um usuário que tem todas as permissões). Isso é útil se você precisa criar uma conta inicial de superusuário, mas não o fez durante o syncdb, ou se você precisa programaticamente gerar contas de superusuário para seu(s) site(s).

Quando executar interativamente, este comando pedirá uma senha para a nova conta de super usuário. Quando executá-lo de forma não interativa, nenhuma senha será definida, e a conta de superusuário não será hábil a logar-se até que uma senha seja manualmente definida para ele.

--username¶

--email¶

O nome de usuário e endereço de e-mail para a nova conta podem ser fornecidos usando os argumentos --username e --email na linha de comando. Se algum deles não forem fornecidos, createsuperuser pedirá por eles quando estiver rodando interativamente.

Este comando estará disponível somente se o sistema de autenticação do Django (django.contrib.auth) estiver instalado.

dbshell¶

django-admin.py dbshell¶

Executa o cliente de linha de comando para o engine de banco de dados especificado em sua configuração DATABASE_ENGINE, com os paramêtros de conexão especificados em DATABASE_USER, DATABASE_PASSWORD, etc.

Para PostgreSQL, rodará o cliente de linha de comando psql.
Para MySQL, rodará o cliente de linha de comando mysql.
Para SQLite, rodará o cliente de linha de comando sqlite3.

Este comando assume que os programas estão no seu PATH, de modo que uma simples chamada pelo nome do programa (psql, mysql, sqlite3) encontrará o programa no lugar certo. Não há formas de especificar a localização do programa manualmente.

diffsettings¶

django-admin.py diffsettings¶

Mostra diferenças entre as configurações atuais e as padrões do Django.

Configurações que não aparecem nas padrões são seguidas por "###". Por exemplo, a configuração padrão não define ROOT_URLCONF, então o ROOT_URLCONF é seguido de "###" na saída do diffsettings.

Note que as configurações padrões do Django estão em django/conf/global_settings.py, se você estiver curioso para ver a lista completa delas.

dumpdata¶

django-admin.py dumpdata <appname appname ...>¶

Mostra na saída padrão todos os dados no banco de dados associado às aplicações listadas.

Se nenhum nome de aplicação é fornecido, todas as aplicações instaladas serão extraídas.

A saída de dumpdata pode ser usada como entrada para loaddata.

Note que dumpdata usa o manager padrão do model para selecionar os registros a serem exportados. Se você estiver usando um manager personalizado como manager padrão e ele filtra algumas entradas disponíveis, nem todos os objetos serão exportados.

--exclude¶

Please, see the release notes

Excluí uma aplicação específica das aplicações cujo conteúdo é mostrado. Por exemplo, para especificadamente excluir a aplicação auth da saída, você deve chamar:

django-admin.py dumpdata --exclude=auth

Se você deseja excluir várias aplicações, use várias diretivas --exclude:

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

--format <fmt>¶: Por padrão, dumpdata formatará sua saída como JSON, mas você pode usar a opção --format para especificar outro formato. Os formatos atualmente suportados estão listados em Formatos de seriação.

--indent <num>¶: Por padrão, dumpdata exportará todos os dados em uma única linha. Isso não é fácil para humanos lerem, então você pode usar a opção --indent para imprimir uma bela saída com alguns espaços de indentação.

flush¶

Retorna o banco de dados ao estado em que ele estava imediatamente após a execução do syncdb. Isto significa que todos os dados serão removidos do banco de dados, quaisquer manipuladores de sincronização posterior, serão re-executados, e o fixture initial_data será reinstalado.

--noinput¶: Use a opção --noinput para suprimir todo prompt para o usuário, como as mensagens de confirmação “Você tem certeza?”. Isso é útil se o django-admin.py é executado como um script autônomo.

inspectdb¶

Faz introspecção nas tabelas do banco de dados apontado pela configuração DATABASE_NAME e mostra um módulo de model do Django (um arquivo models.py) na saída padrão.

Use isso se você tem um banco de dados legado com o qual você gostaria de usar o Django. O script irá inspecionar o banco de dados e criar um model para cada tabela dentro dele.

Como você pode esperar, os models criados terão um atributo para todos os campos da tabela. Note que inspectdb tem uns poucos casos especiais em sua saída de nomes de campos:

Se inspectdb não mapear um tipo de coluna para o tipo de campo do model, ele usará um TextField e inserirá um comentário Python 'This field type is a guess' (traduzindo, 'Este tipo de campo é uma advinhação'.) próximo ao campo gerado no model.
Se o nome da coluna do banco de dados é uma palavra reservada do Python (tipo 'pass', 'class' ou 'for'), o inspectdb adicionará '_field' ao nome do atributo. Por exemplo, se uma tabela tem uma coluna 'for', o model gerado terá um campo 'for_field', com o atributo db_column setado para 'for'. O inspectdb inserirá o comentário Python 'Field renamed because it was a Python reserved word' (traduzindo, 'Campo renomeado porque é uma palavra reservada do Python') próximo ao campo.

Esta funcionalidade é para ser um atalho, não um gerador de models definitivo. Depois que você rodá-la, você precisará mexer nos models para personalizá-lo. Em particular, você precisará reorganizar a ordem dos models, desta forma os models que são referenciados por outros, funcionarão apropriadamente.

Chaves primárias são automaticamente introspectadas no PostgreSQL, MySQL e SQLite, nestes casos o Django coloca primary_key=True onde for necessário.

O inspectedb trabalha com PostgreSQL, MySQL e SQLite. Detecção de chaves estrangeiras somente funcionam no PostgreSQL e com certos tipos de tabelas do MySQL.

loaddata <fixture fixture ...>¶

Procura e carrega os conteúdos de fixtures para dentro do banco de dados.

Um fixture é uma coleção de arquivos que contém os conteúdos serializados do banco de dados. Cada fixture tem um nome único, e os arquivos que compreendem aos fixtures podem estar distribuídos em vários diretórios, em várias aplicações.

O Django procurará em três lugares por fixtures:

No diretório fixtures de cada aplicação instalada
Em qualquer diretório encontrado na configuração FIXTURE_DIRS
No caminho literal nomeado para o fixture

O Django carregará qualquer e todos os fixtures que encontrar, nos lugares que combinarem com os nomes de fixtures fornecidos.

Se o fixture nomeado tem uma extensão de arquivo, somente fixtures daquele tipo serão carregados. Por exemplo:

django-admin.py loaddata mydata.json

poderia somente carregar fixtures JSON chamados mydata. A extensão do fixture deve corresponder ao nome registrado do serializador (e.g., json ou xml).

Se você omitir a extensão, o Django procurará todos os tipos de fixtures disponíveis até encontrar uma combinação. Por exemplo:

django-admin.py loaddata mydata

poderia procurar por qualquer fixture de qualquer tipo chamado mydata. Se um diretório de fixture contendo mydata.json, cujo a fixture poderia ser carregada como uma fixture JSON. Entretanto, se duas fixtures com o mesmo nome mas tipos diferentes forem descobertas (por exemplo, se mydata.json e mydata.xml fossem encontradas em algum diretório de fixtures), a instalação do fixtures será abortada, e qualquer dado instalado na chamada do loaddata será removido do banco de dados.

Os fixtures que são nomeados podem incluir componentes de diretório. Estes diretórios serão incluídos no caminho de busca. Por exemplo:

django-admin.py loaddata foo/bar/mydata.json

poderia procurar <appname>/fixtures/foo/bar/mydata.json para cada aplicação instalada, <dirname>/foo/bar/mydata.json para cada diretório no FIXTURE_DIRS, e o caminho literal foo/bar/mydata.json.

Quando arquivos fixture são processados, os dados são salvos no banco de dados como estão. O método save do model definido e o sinal pre_save não são chamados.

Note que a ordem em que os arquivos de fixtures são processados é indefinida. Entretanto, todos os dados são instalados como uma transação única, então, dados de uma fixture podem referenciar dados de outra fixture. Se o backend de banco de dados suporta constraints a nível de linha, estes constraints serão checados no final da transação.

O comando dumbdata pode ser usado para gerar entrada para loaddata.

MySQL e Fixtures

Infelizmente, o MySQL não é capaz de suportar completamente todas as funcionalidades dos fixtures do Django. Se você usa tabelas MyISAM, o MySQL não suporta transações ou constraints, então você não pode fazer um rollback se vários arquivos de transação são encontrados, ou fixtures com dados de validação.Se você usa tabelas InnoDB, você não poderá ter qualquer referência nos seus arquivos de dados - o MySQL não provê um mecanismo para diferir checagens de constraints de linhas até que uma transação seja comitada.

–verbosity¶

Use --verbosity para especificar o quanto de notificações e informações de debug o django-admin.py deverá imprimir no console.

0 significa nenhuma saída.
1 significa saída normal (padrão).
2 significa saída prolixa.

Exemplo de uso:

django-admin.py loaddata --verbosity=2

makemessages¶

Antes da versão 1.0 este era o comando bin/make-messages.py.

Executa sobre toda árvore de código do diretório atual e extrai todas as strings marcadas para tradução. Ele cria (ou atualiza) um arquivo de mensagem em conf/locale (na árvore do django) ou um diretório locale (para o projeto e aplicação). Depois de fazer as mudanças nos arquivos de mensagens você precisará compilá-los com compilemessages para usar com o suporte ao gettext embutido. Veja a documentação i18n para detalhes.

–all¶

Use as opções --all ou -a para atualizar os arquivos de mensagens para todas os idiomas disponíveis.

Exemplo de uso:

django-admin.py makemessages --all

–extension¶

Use as opções --extension ou -e para especificar uma lista de extensões de arquivos para examinar (padrão: ”.html”).

Exemplo de uso:

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

Separe as várias extensões com vírgulas ou usando -e ou –extension várias vezes:

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

–locale¶

Use as opções --locale ou -l para especificar o locale a ser processado.

Exemplo de uso:

django-admin.py makemessages --locale=pt_BR

–domain¶

Use as opções --domain ou -d para mudar o domínio dos arquivos de mensagens. Atualmente são suportados:

django para todo arquivo *.py e *.html (padrão)
djangojs para arquivos *.js

–verbosity¶

Use --verbosity para especificar o quanto de notificações e informações de debug o django-admin.py deverá imprimir no console.

0 significa nenhuma saída.
1 significa saída normal (padrão).
2 significa saída prolixa.

Exemplo de uso:

django-admin.py makemessages --verbosity=2

reset <appname appname ...>¶

Executa o equivalente a sqlreset para uma app específica.

–noinput¶

Use a opção --noinput para suprimir todo prompt ao usuário, como mensagens de confirmação “Você tem certeza?”. Isso é útil se o django-admin.py for executado de forma autônoma, por um script.

runfcgi [options]¶

Inicia um conjunto de processos FastCGI adequados para uso com qualquer servidor Web que suporta o protocolo FastCGI. Veja a documentação de implantação no FastCGI para detalhes. Requer o módulo FastCGI do Python flup.

runserver¶

django-admin.py runserver [port or ipaddr:port]¶

Inicia um servidor Web leve de desenvolvimento na máquina local. Por padrão, o servidor roda na porta 8000 no endereço IP 127.0.0.1. Você pode passar um endereço IP e uma porta explicitamente.

Se você executar este script como um usuário com privilégios normais (recomendado), você pode não ter permissão para poder iniciar o servidor numa porta de número baixo. Portas de números baixos são reservadas ao super-usuário (root).

NÃO USE ESTE SERVIDOR EM AMBIENTE DE PRODUÇÃO. Ele não passou por auditorias de segurança ou testes de desempenho. (E isso vai ficar como está. Nosso negócio é fazer um framework Web, não servidores Web, portanto, improvisar este servidor para torná-lo usável em ambiente de produção está fora do escopo do Django.)

O servidor de desenvolvimento recarrega o código Python a cada request, se necessário. Você não precisa reiniciá-lo para que mudanças no código tenham efeito.

Quando iniciar o servidor, a cada vez que você mudar o código Python enquanto ele estiver rodando, o servidor validará todos os seus models instalados. (Veja o comando validate abaixo.) Se o validador encontrar erros, ele os imprimirá na saída padrão, mas não parará o servidor.

Você pode rodar quantos servidores você quiser, desde que estejam em portas separadas. É só executar django-admin.py runserver mais de uma vez.

Note que o endereço IP padrão, 127.0.0.1, não é acessível para outros computadores de sua rede. Para ter seu servidor de desenvolvimento visível por outros na rede, use seu próprio endereço IP (e.g. 192.168.2.1) ou 0.0.0.0.

--adminmedia¶

Use a opção --adminmedia para dizer ao Django onde encontrar os vários arquivos CSS e JavaScript da interface de administração do Django. Normalmente, o servidor de desenvolvimento serve estes arquivos da árvore de código do Django magicamente, mas você pode querer usar isso, caso tenha feito quaisquer mudanças nos arquivos para seu próprio site.

Exemplo de uso:

django-admin.py runserver --adminmedia=/tmp/new-admin-style/

--noreload¶

Use a opção --noreload para desabilitar o uso do auto-reloader. Isso significa que quaisquer mudanças no código Python, feitas enquanto o servidor estiver rodando, não terá efeito se o módulo em particular já foi carregado na memória.

Exemplo de uso:

django-admin.py runserver --noreload

Exemplos de uso com diferentes portas e endereços¶

Porta 8000 no endereço IP 127.0.0.1:

django-admin.py runserver

Porta 8000 no endereço IP 1.2.3.4:

django-admin.py runserver 1.2.3.4:8000

Porta 7000 no endereço IP 127.0.0.1:

django-admin.py runserver 7000

Porta 7000 no endereço IP 1.2.3.4:

django-admin.py runserver 1.2.3.4:7000

Servindo arquivos estáticos com o servidor de desenvolvimento¶

Por padrão, o servidor de desenvolvimento não serve quaisquer arquivos estáticos para o site (como arquivos CSS, imagens, coisas sob o MEDIA_URL, etc). Se você deseja configurar o Django para servir arquivos de mídia estáticos, leia Como servir arquivos estáticos.

shell¶

Começa o interpretador Python interativo.

O Django usará o IPython, se ele estiver instalado. Se você tem o IPython instalado e quer forçar o uso do interpretador Python “plano”, use a opção --plain, desta forma:

django-admin.py shell --plain

sql <appname appname ...>¶

Imprime a consulta SQL CREATE TABLE para as app name fornecidas.

sqlall <appname appname ...>¶

Imprime as consultas SQL CREATE TABLE e initial-data, para as app name fornecidas.

Leia a descrição de sqlcustom para uma explicação de como especificar dados iniciais.

sqlclear <appname appname ...>¶

Imprime a consulta SQL DROP TABLE para as app name fornecidas.

sqlcustom <appname appname ...>¶

Imprime a consulta SQL para as app name fornecidas.

Para cada model em cada app especificada, este comando procura pelo arquivo <appname>/sql/<modelname>.sql, onde <appname> é o nome dado da aplicação <modelname> é o nome do model em minúsculo. Por exemplo, se você tem uma app news que inclui um model Story, o sqlcustom tentará ler o arquivo news/sql/story.sql e irá adicionar à saída deste comando.

Cada arquivo SQL, se fornecido, é esperado que contenha SQL válido. Os arquivos SQL são entubados diretamente dentro do banco de dados depois que todos as consultas de criação de tabelas foram executadas. Use este hook SQL para fazer quaisquer modificações em tabelas, ou inserir qualquer função SQL dentro do banco de dados.

Note que a ordem em que os arquivos SQL são processados é indefinida.

sqlflush¶

Imprime a instrução SQL que será executada pelo comando flush.

sqlindexes <appname appname ...>¶

Imprime a instrução SQL CREATE INDEX SQL para as app name fornecidas.

sqlreset <appname appname ...>¶

Imprime o SQL DROP TABLE, seguido do SQL CREATE TABLE, para as app name fornecidas.

sqlsequencereset <appname appname ...>¶

Imprime as instruções SQL para resetar as seqüencias das app name fornecidas.

Seqüências são índices usados por alguns bancos de dados para rastrear o próximo número disponível automaticamente, em campos incrementais.

Use este comando para gerar SQL que consertará casos em que uma sequência está fora de sincronia com seus dados de campos automaticamente incrementados.

startapp <appname>¶

Cria uma estrutura de diretório de aplicação Django com o nome fornecido, no diretório corrente.

startproject <projectname>¶

Cria uma estrutura de diretório de projeto Django com o nome fornecido, no diretório corrente.

Este comando é desabilitado quando a opção --settings para o django-admin.py é usado, ou quando a variável de ambiente DJANGO_SETTINGS_MODULE estiver definida. Para rehabilitá-lo nestas situações, deve-se omitir a opção --settings ou anular o DJANGO_SETTINGS_MODULE.

syncdb¶

Cria as tabelas do banco de dados para todas as aplicações em INSTALLED_APPS cujo as tabelas ainda não foram criadas.

Use este comando quando você tiver adicionado novas aplicações ao seu projeto e quer instalá-las no banco de dados. Isso inclui quaisquer aplicações entregues com o Django, que podem estar no INSTALLED_APPS por padrão. Quando você iniciar um novo projeto, execute este comando para instalar as aplicações padrão.

syncdb não altera tabelas existentes

syncdb somente criará tabelas para os models que não foram instalados ainda. Ele nunca emite uma consulta ALTER TABLE para combinar mudanças feitas na classe do model depois da instalação. Mudanças de models e esquemas de banco de dados normalmente envolvem alguma forma de ambiguidade e, em alguns casos, o Django não adivinhará quais as mudanças corretas fazer. Há um risco de que dados críticos poderiam ser perdidos no processo.

Se você tem feito mudanças em models e deseja alterar as tabelas do banco de dados, use o comando sql para mostrar a nova estrutura do SQL e compare-a com o seu esquema de tabelas atual, para fazer as mudanças.

Se você estiver instalando a aplicação django.contrib.auth, o syncdb dará a você a opção de criar um superusuário imediatamente.

O syncdb também procurará por, e instalará, qualquer fixture chamada initial_data com uma extenção apropriada (e.g. json ou xml). Veja a documentação para loaddata para detalhes sobre a especificação de arquivos de dados de fixture.

–verbosity¶

Use --verbosity para especificar o quanto de notificações e informações de debug o django-admin.py deverá imprimir no console.

0 significa nenhuma saída.
1 significa saída normal (padrão).
2 significa saída prolixa.

Exemplo de uso:

django-admin.py syncdb --verbosity=2

–noinput¶

Use a opção --noinput para suprimir todo prompt ao usuário, como mensagens de confirmação “Você tem certeza?”. Isso é útil se o django-admin.py for executado de forma autônoma, por um script.

test¶

Executa os testes para todos os models instalados. Veja Testando aplicações Django para mais informações.

–noinput¶

Use a opção --noinput para suprimir todo prompt ao usuário, como mensagens de confirmação “Você tem certeza?”. Isso é útil se o django-admin.py for executado de forma autônoma, por um script.

–verbosity¶

Use --verbosity para especificar o quanto de notificações e informações de debug o django-admin.py deverá imprimir no console.

0 significa nenhuma saída.
1 significa saída normal (padrão).
2 significa saída prolixa.

Exemplo de uso:

django-admin.py test --verbosity=2

testserver <fixture fixture ...>¶

Please, see the release notes

Executa um servidor de desenvolvimento Django (como no runserver) usando dados de fixture(s) fornecida(s).

Por exemplo, este comando:

django-admin.py testserver mydata.json

...executaria os seguintes passos:

Cria um banco de dados de teste, como descrito em Testando aplicações Django.
Popula o banco de dados de teste com os dados das fixtures. (Para saber mais sobre fixtures, veja a documentação para loaddata acima.)
Executa o servidor de desenvolvimento do Django (como no runserver), apontando para este novo banco de dados criado, ao invés do seu banco de dados de produção.

Isso é útil de diversas formas:

Quando você estiver escrevendo unit tests de como seus views agem com certos dados de fixture, você pode usar testserver para interagir com os views no navegador Web, manualmente.
Vamos dizer que você está desenvolvendo sua aplicação Django e tem uma cópia antiga do banco de dados com a qual você gostaria de interagir. Você pode extrair seu banco de dados para uma fixture (usando o comando dumpdata, explicado acima), e então usar testserver para rodar sua aplicação Web com estes dados. Com este arranjo, você tem a flexibilidade de interagir com seus dados de qualquer forma, sabendo que qualquer dado alterado está tendo efeito somente no seu banco de dados de teste.

Note que este servidor não detecta automaticamente mudanças no seu código Python (como runserver faz). Ele, no entanto, detecta mudanças nos seus templates.

–addrport [número da porta ou ipaddr:port]¶

Use --addrport para especificar uma porta diferente, ou endereço de IP e porta, no padrão 127.0.0.1:8000. Este valor segue exatamente o mesmo formato e exerce a mesma função do argumento para o subcomando runserver.

Exemplos:

Para rodar o servidor de test na porta 7000 com o fixture1 e fixture2:

django-admin.py testserver --addrport 7000 fixture1 fixture2
django-admin.py testserver fixture1 fixture2 --addrport 7000

(As regras acima são equivalente. Nós incluímos ambas para demonstrar que não importa se as opções vem antes ou depois dos argumentos de fixture.)

Para rodar sobre 1.2.3.4:7000 um fixture test:

django-admin.py testserver --addrport 1.2.3.4:7000 test

–verbosity¶

Use --verbosity para especificar o quanto de notificações e informações de debug o django-admin.py deverá imprimir no console.

0 significa nenhuma saída.
1 significa saída normal (padrão).
2 significa saída prolixa.

Exemplo de uso:

django-admin.py testserver --verbosity=2

validate¶

Valida todos os models instalados (de acordo com a configuração INSTALLED_APPS) e imprime erros de validação na saída padrão.

Opções padrão¶

Embora alguns subcomandos possam permitir suas próprias opções personalizadas, todo subcomando permite as seguintes opções:

–pythonpath¶

Exemplo de uso:

django-admin.py syncdb --pythonpath='/home/djangoprojects/myproject'

Adiciona o caminho do sistema de arquivos para o caminho de busca do Python. Se este não for fornecido, o django-admin.py usará a variável de ambiente PYTHONPATH.

Note que esta opção é desnecessária para o manage.py, pois ele se preocupa em definir o caminho do Python por você.

–settings¶

Exemplo de uso:

django-admin.py syncdb --settings=mysite.settings

Explicitamente especifica o módulo settings a se usar. O módulo settings deve estar na sintaxe de pacotes Python, e.g. mysite.settings. Se este não for fornecido, django-admin.py usará a variável de ambiente DJANGO_SETTINGS_MODULE.

Note que esta opção é desnecessária no manage.py, pois ele usa o settings.py do projeto atual por padrão.

–traceback¶

Exemplo de uso:

django-admin.py syncdb --traceback

Por padrão, django-admin.py mostrará uma mensagem de erro simples sempre que um erro ocorrer. Se você especificar --traceback, o django-admin.py mostrará uma pilha completa sempre que uma exceção for lançada.

Sutilezas extra¶

Sintaxe colorida¶

Os comandos django-admin.py / manage.py que mostram SQL na saída padrão usarão uma saída de código colorida se seu terminal suporta saída ANSI-colored. Ele não usa os códigos de cor se você estiver tunelando comandos para um outro programa.

Bash completion¶

Se você usa o terminal Bash, considere instalar o script de Bash completion do Django, que reside em extras/django_bash_completion na distribuição do Django. Ele habilita o auto completar com tab dos comandos django-admin.py e manage.py, então você pode, por instância...

Escrever django-admin.py.
Precionar [TAB] para ver todas as opções disponíveis.
Escrever sql, então [TAB], para ver todas as opções disponíveis cujo nome começa com sql.

Veja Escrevendo commando customizados para o django-admin para saber como adicionar ações personalizadas.