django-adminLink para este cabeçalho#As aplicações podem registrar suas próprias ações com manage.py. Por exemplo, você pode querer adicionar uma ação manage.py para uma aplicação Django que você está distribuindo. Neste documento, construiremos um comando customizado closepoll para a aplicação polls do tutorial.
Pra tal, adicione um diretório management/commands a sua aplicação. O Django irá registrar um comando manage.py para cada módulo Python dentro deste diretório, cujo o nome não inicie com underscore. Por exemplo:
polls/\n __init__.py\n models.py\n management/\n __init__.py\n commands/\n __init__.py\n _private.py\n closepoll.py\n tests.py\n views.py\nNeste exemplo, o comando closepoll estará disponível a qualquer projeto que inclua a aplicação polls em INSTALLED_APPS.
O módulo _private.py não estará disponível como um comando de gerenciamento.
O módulo closepoll.py tem apenas uma exigência – deve definir uma classe Command que estende BaseCommand ou uma de suas subclasses.
Para implementar o comando, edite polls/management/command/closepoll.py para que fique assim:
from django.core.management.base import BaseCommand, CommandError\nfrom polls.models import Question as Poll\n\nclass Command(BaseCommand):\n help = 'Closes the specified poll for voting'\n\n def add_arguments(self, parser):\n parser.add_argument('poll_id', nargs='+', type=int)\n\n def handle(self, *args, **options):\n for poll_id in options['poll_id']:\n try:\n poll = Poll.objects.get(pk=poll_id)\n except Poll.DoesNotExist:\n raise CommandError('Poll "%s" does not exist' % poll_id)\n\n poll.opened = False\n poll.save()\n\n self.stdout.write(self.style.SUCCESS('Successfully closed poll "%s"' % poll_id))\nO novo comando personalizado pode ser chamado usando python manage.py closepoll <poll_id>.
O método handle() recebe um ou mais poll_ids e definie poll.opened como False para cada um. Se o usuário referenciar uma enquete inexistente, uma CommandError é gerada. O atributo poll.opened não existe no tutorial e foi adicionado ao polls.models.Question para este exemplo.
O mesmo closepoll poderia ser facilmente modificado para excluir uma determinada enquete, ao invés de fechá-la, aceitando as opções de linha de comando adicionais. Estas opções personalizadas podem ser adicionadas no método add_arguments() assim:
class Command(BaseCommand):\n def add_arguments(self, parser):\n # Positional arguments\n parser.add_argument('poll_id', nargs='+', type=int)\n\n # Named (optional) arguments\n parser.add_argument(\n '--delete',\n action='store_true',\n dest='delete',\n help='Delete poll instead of closing it',\n )\n\n def handle(self, *args, **options):\n # ...\n if options['delete']:\n poll.delete()\n # ...\nA opção (delete no nosso exemplo) está disponível no parâmetro dict (options) do método handle. Veja argparse na documentação do Python para saber mais sobre o uso do add_argument.
Além de ser capaz de adicionar opções personalizadas de linha de comando, todos comandos de gereciamento aceitam algumas opções padrão, tais como :opção:`--verbosity` e :opção:`--traceback`.
\nPor padrão, o método BaseCommand.execute() desativa traduções porque alguns comandos internos do Django executam várias tarefas (por exemplo, renderização de conteúdo voltado ao usuário e popular o banco de dados) que exigem uma língua neutra no projeto.
Se por algum motivo, o seu comando personalizado de gerenciamento precisar usar uma localidade fixa, você deve ativar e desativar manualmente no método handle() usando as funções fornecidas pelo código de apoio I18N:
from django.core.management.base import BaseCommand, CommandError\nfrom django.utils import translation\n\nclass Command(BaseCommand):\n ...\n\n def handle(self, *args, **options):\n\n # Activate a fixed locale, e.g. Russian\n translation.activate('ru')\n\n # Or you can activate the LANGUAGE_CODE # chosen in the settings:\n from django.conf import settings\n translation.activate(settings.LANGUAGE_CODE)\n\n # Your command logic here\n ...\n\n translation.deactivate()\nOutra necessidade pode ser que o seu comando simplesmente deva utilizar a definição de localidade definida no settings e o Django deve ser impedido de desativá-lo. Você pode fazer isso usando a opção BaseCommand.leave_locale_alone.
Porém, ao trabalhar nos cenários descritos acima, leve em consideração que comandos de gerenciamento de sistemas tipicamente tem que ser muito cuidadosos sobre o funcionamento em locais não-uniformes, de modo que você pode precisar:
\nVerificar se o USE_I18N é sempre True ao executar o comando (este é um bom exemplo dos potenciais problemas decorrentes de um ambiente de execução dinâmico que comandos do Django evitam desativando traduções).
Rever o código do seu comando e o código que este chama para diferenças de comportamento quando as localidades são alteradas e avaliar o seu impacto sobre o comportamento previsível de seu comando.
Informações sobre como testar comandos de gerenciamento personalizados pode ser encontradas na documentação de teste.
\nDjango registra os comandos internos e depois procura os comandos em INSTALLED_APPS. Durante a busca, se for encontrado um comando que já tiver sido registrado, o comando encontrado substitui o primeiro.
Em outras palavras, para sobrescrever um comando, o novo comando precisa ter o mesmo nome e seu app precisa estar antes do comando da app a ser sobrescrito em : setting:INSTALLED_APPS.
\nComando de gerenciamento de apps de terceiros que foram sobrescritos sem querer podem se tornar disponíveis sobre um novo nome pela criação de um novo comando em um dos apps do projeto (ordenado antes do app de terceiros em :setting:`INSTALLED_APPS) que importe o ‘Comando’ do comando sobrescrito.
\nA classe base a partir da qual todos os comandos de gestão, em última análise derivam.
\nUse esta classe se você quer acesso a todos os mecanismos que realizam o parse dos argumentos da linha de comando e verificar qual código chamar em resposta; se você não precisa mudar este comportamento, considere usar uma dessas subclasses.
\nSubclasssing a classe BaseCommand requer que você implemente o método handle().
Todos os atributos podem ser definidos em sua classe derivada e podem ser usados nas subclasses de BaseCommand
Uma breve descrição do comando, que será impresso na mensagem de ajuda quando o usuário executar o comando python manage.py help <command>.
Se o seu comando define argumentos posicionais obrigatórios, você pode personalizar a mensagem de erro devolvida em caso de falta de argumentos. O padrão é a saída por argparse (“poucos argumentos”).
Um booleano que indica como os comandos retornam SQL “statements”; Se True, a saída será automaticamente envolvido com BEGIN; e COMMIT;. O valor padrão é False.
Um booleano; Se True, o comando “printa” um alerta se a definição das migrações no disco não estiver de acordo com as migrações no banco de dados. Um alerta não previne o comando de ser executado. O valor padrão é False.
Um booleano; Se True, todo o projeto Django será verificado sobre potenciais problemas antes de executar o comando. O valor padrão é True.
A boolean indicating whether the locale set in settings should be preserved\nduring the execution of the command instead of translations being\ndeactivated.
\nO valor padrão é False.
Make sure you know what you are doing if you decide to change the value of\nthis option in your custom command if it creates database content that\nis locale-sensitive and such content shouldn’t contain any translations\n(like it happens e.g. with django.contrib.auth permissions) as\nactivating any locale might cause unintended effects. See the Management\ncommands and locales section above for further details.
Um atributo de instância que ajuda a criar uma saída colorida quando se escreve no stdout ou stderr. Por exemplo:
self.stdout.write(self.style.SUCCESS('...'))\nVeja sintaxe-coloring para aprender como modificar a paleta de cores e ver os estilos disponíveis (use caixa-alta das versões das opções descritas nessa seção).
\nSe você passar a opção --no-color ao executar o seu comando, todas as chamadas self.style() retornarão a string original sem colorir.
BaseCommand tem alguns métodos que podem ser sobrescritos mas apenas o método handle() deve ser implementado.
Ponto de entrada que recebe argumentos do “parser” para manipular comandos passados pela linha de comando. Comandos personalizados devem sobrescrever este método para adicionar ambos argumentos posicionais ou opicionais que sejam aceitos pelo comando. Não é necessário chamar o super() quando for uma subclasse de BaseCommand.
Retorna a versão do Django, que deve estar correto para todos os comandos internos do Django. É possível sobrescrever este método para que comandos fornecidos pelo usuário possam retornar a sua própria versão.
\nTenta executar este comando, realizando verificações de sistemas se necessário (como controlado pelo atributo requires_system_checks). Se o comando gerar um CommandError, este é interceptado e impresso no stderr.
A lógica atual do comando. Subclasses devem implementar este método.
\nIt may return a string which will be printed to stdout (wrapped\nby BEGIN; and COMMIT; if output_transaction is True).
Usa a estrutura de verificação do sistema para inspecionar todo o projeto Django para os potenciais problemas. Graves problemas são levantados como CommandError; avisos são enviados para stderr; notificações menos importantes são enviados para stdout.
Se ambos app_configs e tags forem None, todas as verificações do sistema são realizadas. `` Tags`` pode ser uma lista tags de checagem, como compatibility ou models.
BaseCommandLink para este cabeçalho#Um comando de gestão que recebe como argumento um ou mais “labels” de aplicações instaladas, e faz alguma coisa com cada um deles.
\nMelhor que implementar handle(), as subclasses devem implementar :meth:` ~AppCommand.handle_app_config`, que será chamado uma vez para cada aplicação.
Executar ações do comando para app_config, o qual será uma instância de AppConfig correspondente a um label do aplicativo informado na linha de comando.
Um comando de gestão que recebe um ou mais argumentos arbitrários (“labels”) na linha de comando, e faz alguma coisa com cada um deles.
\nEm vez de implementar handle(), subclasses devem implementar handle_label(), que será chamado uma vez para cada etiqueta.
Uma string que descreve os argumentos arbitrários passados para o comando. A string é usada no texto de uso e mensagens de erro do comando. Padrão para `` ‘label’``.
\nExecutar ações do comando para label, que será a string como informada na linha de comando.
A classe de exceção indica um problema ao executar um comando de gestão.
\nSe esta exceção é gerada durante a execução de um comando de gerenciamento chamado do console da linha de comando, ele será capturado e transformado em uma mensagem de erro devidamente impresso para a saída apropriada (isto é, stderr); como resultado, gerar essa exceção (com uma descrição sensata do erro) é a maneira preferida para indicar que algo deu errado na execução de um comando.
\nSe um comando de gestão é chamado do código através do call_command(), cabe a você capturar a exceção quando necessário.