django-admin customizadosLink 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.
Para fazer isso, adicione um diretório management/commands na aplicação. Django irá registrar um comando manage.py para cada módulo Python naquele diretório cujo nome não comece com um sublinhado. 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/commands/closepoll.py para que fique assim:
from django.core.management.base import BaseCommand, CommandError\nfrom polls.models import Question as Poll\n\n\nclass Command(BaseCommand):\n help = "Closes the specified poll for voting"\n\n def add_arguments(self, parser):\n parser.add_argument("poll_ids", nargs="+", type=int)\n\n def handle(self, *args, **options):\n for poll_id in options["poll_ids"]:\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(\n self.style.SUCCESS('Successfully closed poll "%s"' % poll_id)\n )\nO novo comando personalizado pode ser chamado usando python manage.py closepoll <poll_ids>.
O método handle() usa um ou mais poll_ids e altera o “poll.opened” para False para cada um. Se o usuário referenciar qualquer enquete inexistente, uma exceção será levantada CommandError. O atributo poll.opened não existe no tutorial e foi adicionado em 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_ids", nargs="+", type=int)\n\n # Named (optional) arguments\n parser.add_argument(\n "--delete",\n action="store_true",\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, comandos de gerenciamento são executados com a localidade corrente ativa.
\nSe, por alguma razão, seu comando de gerenciamento personalizado precise ser executado sem um local ativo (por exemplo, para evitar que o conteúdo traduzido seja inserido dentro do banco de dados), desative a tradução utilizado o decorator @no_translations no seu método handle():
from django.core.management.base import BaseCommand, no_translations\n\n\nclass Command(BaseCommand):\n ...\n\n @no_translations\n def handle(self, *args, **options): ...\nComo a desativação da tradução requer acesso as configurações definidas, os decorator’s não podem ser utilizados por comandos que trabalham sem configurações pré definidas.
\nInformaçõ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 em orderm reversa. Durante a busca, se um comando duplica um comando já registrado, o novo 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.
\nComandos de gerenciamento de aplicações de terceiros que foram sobrescritos de maneira nao intencional podem se tornar disponíveis sob um novo nome através da criação de um novo comando em um dos apps do projeto (colocado antes da aplicação de terceiros em :setting:`INSTALLED_APPS) o qual importa 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 o conjunto de 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.
Uma lista ou tupla de tags, e. g. “[Tags.staticfiles, Tags.models]”. O sistema checa :ref’registrado nas tags escolhidas’ <registering-labeling-checks>’serão verificados por erros antes de executar o comando. O valor “__all__” pode ser usado para especificar que todas as checagens devem ser realizadas. Valor pré-definido é “__all__”
\nUm 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.
As opções de comando padrão a serem suprimidas na saída de ajuda. Este deve ser um conjunto de nomes de opções (por exemplo, '--verbosity'). Os valores padrão para as opções suprimidas ainda são passados.
BaseCommand tem alguns métodos que podem ser sobrescritos mas apenas o método handle() deve ser implementado.
Retorna uma instância de CommandParser, o qual é uma classe: argparse.ArgumentParser subclasse, com algumas personalizações para o Django.
Você pode customizar a instância por sobrecarga desse método, chamando super() com kwargs da classe:~argparse.ArgumentParser como parâmetro.
Ponto de entrada para passar um “parser” como argumento para lidar com os argumentos da linha de comando passados ao comando. Comandos personalizados devem sobrescrever este método para adicionar ambos argumentos posicionais e opicionais aceitos pelo comando. Não é necessário chamar o super() quando for uma subclasse de BaseCommand.
Retorna a versão do Django, que deve ser a correta 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, verificando o sistema se necessário (conforme controlado pelo atributo requires_system_checks). Se o comando gera um CommandError, ele é interceptado e impresso em stderr.
A lógica atual do comando. Subclasses devem implementar este método.
\nPode retornar uma string tal qual será impressa no “stdout” (acrescido por “BEGIN;” e “COMMIT;” se :attr:’output_transaction’ for “True”).
\nUsa a estrutura de verificação do sistema para inspecionar todo o projeto Django em busca de possíveis problemas. Problemas sérios são levantados como CommandError; avisos são emitidos para stderr; notificações menores são enviadas para stdout.
Se app_configs e tags forem ambas None, todas as checagens do sistema serão performadas exceto checagens relacionados à implatanção e banco de dados. tags pode ser uma lista de rótulos para verificar, como compatibility ou models.
Você pode informar include_deployment_checks=True para também executar verficações de implantação, e uma lista de apelidos de banco de dados em databases para executar verificações relacionadas à banco de dados nestes.
Supplies kwargs for the call to check(), including transforming the\nvalue of requires_system_checks to the tag kwarg.
Override this method to change the values supplied to check(). For\nexample, to opt into database related checks you can override\nget_check_kwargs() as follows:
def get_check_kwargs(self, options):\n kwargs = super().get_check_kwargs(options)\n return {**kwargs, "databases": [options["database"]]}\nBaseCommandLink para este cabeçalho#Um comando de gerenciamento que recebe como argumento um ou mais “labels” de aplicação instaladas, e faz alguma coisa com cada um deles.
\nMelhor que implementar handle(), as subclasses devem implementar :meth:` ~AppCommand.handle_app_config`, o qual 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 for gerada durante a execução de um comando de gerenciamento a partir de um console de linha de comando, ela será capturada e transformada em uma mensagem de erro bem impressa para o fluxo de saída apropriado (ou seja, stderr); como resultado, levantar essa exceção (com uma descrição sensata do erro) é a maneira preferida de indicar que algo deu errado na execução de um comando. Ele aceita o argumento opcional returncode para personalizar o status de saída para o comando de gerenciamento sair, usando sys.exit().
Se um comando de gestão é chamado do código através do call_command(), cabe a você capturar a exceção quando necessário.