2016-01-24 21:26:11 +00:00
|
|
|
|
========================================
|
|
|
|
|
Writing custom ``django-admin`` commands
|
|
|
|
|
========================================
|
2008-08-23 22:25:40 +00:00
|
|
|
|
|
2012-12-29 15:35:12 +00:00
|
|
|
|
.. module:: django.core.management
|
|
|
|
|
|
2008-08-23 22:25:40 +00:00
|
|
|
|
Applications can register their own actions with ``manage.py``. For example,
|
|
|
|
|
you might want to add a ``manage.py`` action for a Django app that you're
|
2010-06-05 05:26:04 +00:00
|
|
|
|
distributing. In this document, we will be building a custom ``closepoll``
|
2010-05-08 21:38:00 +00:00
|
|
|
|
command for the ``polls`` application from the
|
2010-08-19 19:27:44 +00:00
|
|
|
|
:doc:`tutorial</intro/tutorial01>`.
|
2008-08-23 22:25:40 +00:00
|
|
|
|
|
2010-05-08 21:38:00 +00:00
|
|
|
|
To do this, just add a ``management/commands`` directory to the application.
|
2012-02-17 20:04:11 +00:00
|
|
|
|
Django will register a ``manage.py`` command for each Python module in that
|
|
|
|
|
directory whose name doesn't begin with an underscore. For example::
|
2008-08-23 22:25:40 +00:00
|
|
|
|
|
2010-05-08 21:38:00 +00:00
|
|
|
|
polls/
|
2008-08-23 22:25:40 +00:00
|
|
|
|
__init__.py
|
|
|
|
|
models.py
|
|
|
|
|
management/
|
|
|
|
|
__init__.py
|
|
|
|
|
commands/
|
|
|
|
|
__init__.py
|
2012-02-04 18:27:14 +00:00
|
|
|
|
_private.py
|
2010-05-08 21:38:00 +00:00
|
|
|
|
closepoll.py
|
|
|
|
|
tests.py
|
2008-08-23 22:25:40 +00:00
|
|
|
|
views.py
|
|
|
|
|
|
2014-07-07 22:04:00 +00:00
|
|
|
|
On Python 2, be sure to include ``__init__.py`` files in both the
|
|
|
|
|
``management`` and ``management/commands`` directories as done above or your
|
|
|
|
|
command will not be detected.
|
|
|
|
|
|
2010-05-08 21:38:00 +00:00
|
|
|
|
In this example, the ``closepoll`` command will be made available to any project
|
|
|
|
|
that includes the ``polls`` application in :setting:`INSTALLED_APPS`.
|
|
|
|
|
|
2012-02-04 18:27:14 +00:00
|
|
|
|
The ``_private.py`` module will not be available as a management command.
|
|
|
|
|
|
2010-05-08 21:38:00 +00:00
|
|
|
|
The ``closepoll.py`` module has only one requirement -- it must define a class
|
|
|
|
|
``Command`` that extends :class:`BaseCommand` or one of its
|
|
|
|
|
:ref:`subclasses<ref-basecommand-subclasses>`.
|
|
|
|
|
|
|
|
|
|
.. admonition:: Standalone scripts
|
|
|
|
|
|
2015-01-17 18:38:01 +00:00
|
|
|
|
Custom management commands are especially useful for running standalone
|
|
|
|
|
scripts or for scripts that are periodically executed from the UNIX crontab
|
|
|
|
|
or from Windows scheduled tasks control panel.
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
|
|
|
|
To implement the command, edit ``polls/management/commands/closepoll.py`` to
|
2014-08-18 14:30:44 +00:00
|
|
|
|
look like this::
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
|
|
|
|
from django.core.management.base import BaseCommand, CommandError
|
2012-04-25 06:37:16 +00:00
|
|
|
|
from polls.models import Poll
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
|
|
|
|
class Command(BaseCommand):
|
|
|
|
|
help = 'Closes the specified poll for voting'
|
|
|
|
|
|
2014-06-06 15:55:56 +00:00
|
|
|
|
def add_arguments(self, parser):
|
|
|
|
|
parser.add_argument('poll_id', nargs='+', type=int)
|
|
|
|
|
|
2010-05-08 21:38:00 +00:00
|
|
|
|
def handle(self, *args, **options):
|
2014-06-06 15:55:56 +00:00
|
|
|
|
for poll_id in options['poll_id']:
|
2010-05-08 21:38:00 +00:00
|
|
|
|
try:
|
2014-06-06 15:55:56 +00:00
|
|
|
|
poll = Poll.objects.get(pk=poll_id)
|
2010-05-08 21:38:00 +00:00
|
|
|
|
except Poll.DoesNotExist:
|
|
|
|
|
raise CommandError('Poll "%s" does not exist' % poll_id)
|
|
|
|
|
|
|
|
|
|
poll.opened = False
|
|
|
|
|
poll.save()
|
|
|
|
|
|
2015-11-08 09:47:21 +00:00
|
|
|
|
self.stdout.write(self.style.SUCCESS('Successfully closed poll "%s"' % poll_id))
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
2013-02-09 09:17:26 +00:00
|
|
|
|
.. _management-commands-output:
|
|
|
|
|
|
2010-06-05 05:26:04 +00:00
|
|
|
|
.. note::
|
|
|
|
|
When you are using management commands and wish to provide console
|
|
|
|
|
output, you should write to ``self.stdout`` and ``self.stderr``,
|
|
|
|
|
instead of printing to ``stdout`` and ``stderr`` directly. By
|
|
|
|
|
using these proxies, it becomes much easier to test your custom
|
2013-02-09 09:17:26 +00:00
|
|
|
|
command. Note also that you don't need to end messages with a newline
|
|
|
|
|
character, it will be added automatically, unless you specify the ``ending``
|
|
|
|
|
parameter::
|
|
|
|
|
|
|
|
|
|
self.stdout.write("Unterminated line", ending='')
|
2010-06-05 05:26:04 +00:00
|
|
|
|
|
|
|
|
|
The new custom command can be called using ``python manage.py closepoll
|
2010-05-08 21:38:00 +00:00
|
|
|
|
<poll_id>``.
|
|
|
|
|
|
2014-06-06 15:55:56 +00:00
|
|
|
|
The ``handle()`` method takes one or more ``poll_ids`` and sets ``poll.opened``
|
2011-05-13 04:33:42 +00:00
|
|
|
|
to ``False`` for each one. If the user referenced any nonexistent polls, a
|
2016-01-12 17:28:55 +00:00
|
|
|
|
:exc:`CommandError` is raised. The ``poll.opened`` attribute does not exist in
|
|
|
|
|
the :doc:`tutorial</intro/tutorial01>` and was added to ``polls.models.Poll``
|
|
|
|
|
for this example.
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
2014-06-06 15:55:56 +00:00
|
|
|
|
.. _custom-commands-options:
|
|
|
|
|
|
|
|
|
|
Accepting optional arguments
|
|
|
|
|
============================
|
|
|
|
|
|
2010-05-08 21:38:00 +00:00
|
|
|
|
The same ``closepoll`` could be easily modified to delete a given poll instead
|
2014-06-06 15:55:56 +00:00
|
|
|
|
of closing it by accepting additional command line options. These custom
|
2014-08-18 14:30:44 +00:00
|
|
|
|
options can be added in the :meth:`~BaseCommand.add_arguments` method like this::
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
|
|
|
|
class Command(BaseCommand):
|
2014-06-06 15:55:56 +00:00
|
|
|
|
def add_arguments(self, parser):
|
|
|
|
|
# Positional arguments
|
|
|
|
|
parser.add_argument('poll_id', nargs='+', type=int)
|
|
|
|
|
|
|
|
|
|
# Named (optional) arguments
|
|
|
|
|
parser.add_argument('--delete',
|
2010-05-08 21:38:00 +00:00
|
|
|
|
action='store_true',
|
|
|
|
|
dest='delete',
|
|
|
|
|
default=False,
|
2014-06-06 15:55:56 +00:00
|
|
|
|
help='Delete poll instead of closing it')
|
2012-04-23 18:05:12 +00:00
|
|
|
|
|
|
|
|
|
def handle(self, *args, **options):
|
|
|
|
|
# ...
|
|
|
|
|
if options['delete']:
|
|
|
|
|
poll.delete()
|
|
|
|
|
# ...
|
|
|
|
|
|
|
|
|
|
The option (``delete`` in our example) is available in the options dict
|
2014-06-06 15:55:56 +00:00
|
|
|
|
parameter of the handle method. See the :py:mod:`argparse` Python documentation
|
|
|
|
|
for more about ``add_argument`` usage.
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
2010-06-05 05:26:04 +00:00
|
|
|
|
In addition to being able to add custom command line options, all
|
2016-01-12 01:59:34 +00:00
|
|
|
|
:doc:`management commands</ref/django-admin>` can accept some default options
|
|
|
|
|
such as :option:`--verbosity` and :option:`--traceback`.
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
2013-02-03 23:53:48 +00:00
|
|
|
|
.. _management-commands-and-locales:
|
2011-01-03 14:27:28 +00:00
|
|
|
|
|
2013-02-03 23:53:48 +00:00
|
|
|
|
Management commands and locales
|
|
|
|
|
===============================
|
2011-01-03 14:27:28 +00:00
|
|
|
|
|
2015-01-03 19:27:18 +00:00
|
|
|
|
By default, the :meth:`BaseCommand.execute` method deactivates translations
|
|
|
|
|
because some commands shipped with Django perform several tasks (for example,
|
|
|
|
|
user-facing content rendering and database population) that require a
|
|
|
|
|
project-neutral string language.
|
2011-01-03 14:27:28 +00:00
|
|
|
|
|
2015-01-03 19:27:18 +00:00
|
|
|
|
If, for some reason, your custom management command needs to use a fixed locale,
|
|
|
|
|
you should manually activate and deactivate it in your
|
2014-06-17 23:07:54 +00:00
|
|
|
|
:meth:`~BaseCommand.handle` method using the functions provided by the I18N
|
2014-08-18 14:30:44 +00:00
|
|
|
|
support code::
|
2011-01-03 14:27:28 +00:00
|
|
|
|
|
2013-02-03 23:53:48 +00:00
|
|
|
|
from django.core.management.base import BaseCommand, CommandError
|
|
|
|
|
from django.utils import translation
|
2011-01-03 14:27:28 +00:00
|
|
|
|
|
2013-02-03 23:53:48 +00:00
|
|
|
|
class Command(BaseCommand):
|
|
|
|
|
...
|
|
|
|
|
can_import_settings = True
|
2011-01-03 14:27:28 +00:00
|
|
|
|
|
2013-02-03 23:53:48 +00:00
|
|
|
|
def handle(self, *args, **options):
|
2011-01-03 14:27:28 +00:00
|
|
|
|
|
2013-02-03 23:53:48 +00:00
|
|
|
|
# Activate a fixed locale, e.g. Russian
|
|
|
|
|
translation.activate('ru')
|
|
|
|
|
|
|
|
|
|
# Or you can activate the LANGUAGE_CODE # chosen in the settings:
|
2014-08-18 14:30:44 +00:00
|
|
|
|
from django.conf import settings
|
|
|
|
|
translation.activate(settings.LANGUAGE_CODE)
|
2013-02-03 23:53:48 +00:00
|
|
|
|
|
|
|
|
|
# Your command logic here
|
2014-08-18 14:30:44 +00:00
|
|
|
|
...
|
2011-01-03 14:27:28 +00:00
|
|
|
|
|
2013-02-03 23:53:48 +00:00
|
|
|
|
translation.deactivate()
|
2011-01-03 14:27:28 +00:00
|
|
|
|
|
2013-02-03 23:53:48 +00:00
|
|
|
|
Another need might be that your command simply should use the locale set in
|
2015-01-03 19:27:18 +00:00
|
|
|
|
settings and Django should be kept from deactivating it. You can achieve
|
2013-02-03 23:53:48 +00:00
|
|
|
|
it by using the :data:`BaseCommand.leave_locale_alone` option.
|
2011-01-03 14:27:28 +00:00
|
|
|
|
|
2013-02-03 23:53:48 +00:00
|
|
|
|
When working on the scenarios described above though, take into account that
|
|
|
|
|
system management commands typically have to be very careful about running in
|
|
|
|
|
non-uniform locales, so you might need to:
|
2011-01-03 14:27:28 +00:00
|
|
|
|
|
2013-02-03 23:53:48 +00:00
|
|
|
|
* Make sure the :setting:`USE_I18N` setting is always ``True`` when running
|
|
|
|
|
the command (this is a good example of the potential problems stemming
|
|
|
|
|
from a dynamic runtime environment that Django commands avoid offhand by
|
2015-01-03 19:27:18 +00:00
|
|
|
|
deactivating translations).
|
2011-01-03 14:27:28 +00:00
|
|
|
|
|
2013-02-03 23:53:48 +00:00
|
|
|
|
* Review the code of your command and the code it calls for behavioral
|
|
|
|
|
differences when locales are changed and evaluate its impact on
|
|
|
|
|
predictable behavior of your command.
|
2011-01-03 14:27:28 +00:00
|
|
|
|
|
2014-11-15 11:13:05 +00:00
|
|
|
|
Testing
|
|
|
|
|
=======
|
|
|
|
|
|
|
|
|
|
Information on how to test custom management commands can be found in the
|
|
|
|
|
:ref:`testing docs <topics-testing-management-commands>`.
|
|
|
|
|
|
2010-05-08 21:38:00 +00:00
|
|
|
|
Command objects
|
|
|
|
|
===============
|
|
|
|
|
|
|
|
|
|
.. class:: BaseCommand
|
|
|
|
|
|
|
|
|
|
The base class from which all management commands ultimately derive.
|
|
|
|
|
|
|
|
|
|
Use this class if you want access to all of the mechanisms which
|
|
|
|
|
parse the command-line arguments and work out what code to call in
|
|
|
|
|
response; if you don't need to change any of that behavior,
|
|
|
|
|
consider using one of its :ref:`subclasses<ref-basecommand-subclasses>`.
|
|
|
|
|
|
|
|
|
|
Subclassing the :class:`BaseCommand` class requires that you implement the
|
|
|
|
|
:meth:`~BaseCommand.handle` method.
|
|
|
|
|
|
|
|
|
|
Attributes
|
|
|
|
|
----------
|
|
|
|
|
|
2010-06-05 05:26:04 +00:00
|
|
|
|
All attributes can be set in your derived class and can be used in
|
2013-08-05 16:23:26 +00:00
|
|
|
|
:class:`BaseCommand`’s :ref:`subclasses<ref-basecommand-subclasses>`.
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
|
|
|
|
.. attribute:: BaseCommand.can_import_settings
|
|
|
|
|
|
2015-01-17 18:38:01 +00:00
|
|
|
|
A boolean indicating whether the command needs to be able to
|
|
|
|
|
import Django settings; if ``True``, ``execute()`` will verify
|
|
|
|
|
that this is possible before proceeding. Default value is
|
|
|
|
|
``True``.
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
|
|
|
|
.. attribute:: BaseCommand.help
|
|
|
|
|
|
2015-01-17 18:38:01 +00:00
|
|
|
|
A short description of the command, which will be printed in the
|
|
|
|
|
help message when the user runs the command
|
|
|
|
|
``python manage.py help <command>``.
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
2014-06-06 15:55:56 +00:00
|
|
|
|
.. attribute:: BaseCommand.missing_args_message
|
|
|
|
|
|
2015-01-17 18:38:01 +00:00
|
|
|
|
If your command defines mandatory positional arguments, you can customize
|
|
|
|
|
the message error returned in the case of missing arguments. The default is
|
|
|
|
|
output by :py:mod:`argparse` ("too few arguments").
|
2014-06-06 15:55:56 +00:00
|
|
|
|
|
2010-05-08 21:38:00 +00:00
|
|
|
|
.. attribute:: BaseCommand.output_transaction
|
|
|
|
|
|
2015-01-17 18:38:01 +00:00
|
|
|
|
A boolean indicating whether the command outputs SQL statements; if
|
|
|
|
|
``True``, the output will automatically be wrapped with ``BEGIN;`` and
|
|
|
|
|
``COMMIT;``. Default value is ``False``.
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
2014-01-20 02:45:21 +00:00
|
|
|
|
.. attribute:: BaseCommand.requires_system_checks
|
|
|
|
|
|
2015-01-17 18:38:01 +00:00
|
|
|
|
A boolean; if ``True``, the entire Django project will be checked for
|
|
|
|
|
potential problems prior to executing the command. Default value is ``True``.
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
2013-02-03 23:53:48 +00:00
|
|
|
|
.. attribute:: BaseCommand.leave_locale_alone
|
|
|
|
|
|
2015-01-17 18:38:01 +00:00
|
|
|
|
A boolean indicating whether the locale set in settings should be preserved
|
|
|
|
|
during the execution of the command instead of being forcibly set to 'en-us'.
|
2013-02-03 23:53:48 +00:00
|
|
|
|
|
2015-01-17 18:38:01 +00:00
|
|
|
|
Default value is ``False``.
|
2013-02-03 23:53:48 +00:00
|
|
|
|
|
2015-01-17 18:38:01 +00:00
|
|
|
|
Make sure you know what you are doing if you decide to change the value of
|
|
|
|
|
this option in your custom command if it creates database content that
|
|
|
|
|
is locale-sensitive and such content shouldn't contain any translations
|
|
|
|
|
(like it happens e.g. with django.contrib.auth permissions) as making the
|
|
|
|
|
locale differ from the de facto default 'en-us' might cause unintended
|
|
|
|
|
effects. Seethe `Management commands and locales`_ section above for
|
|
|
|
|
further details.
|
2013-02-03 23:53:48 +00:00
|
|
|
|
|
2015-01-17 18:38:01 +00:00
|
|
|
|
This option can't be ``False`` when the
|
|
|
|
|
:data:`~BaseCommand.can_import_settings` option is set to ``False`` too
|
|
|
|
|
because attempting to set the locale needs access to settings. This
|
2016-01-12 17:28:55 +00:00
|
|
|
|
condition will generate a :exc:`CommandError`.
|
2013-02-03 23:53:48 +00:00
|
|
|
|
|
2015-11-08 09:47:21 +00:00
|
|
|
|
.. attribute:: BaseCommand.style
|
|
|
|
|
|
|
|
|
|
An instance attribute that helps create colored output when writing to
|
|
|
|
|
``stdout`` or ``stderr``. For example::
|
|
|
|
|
|
|
|
|
|
self.stdout.write(self.style.SUCCESS('...'))
|
|
|
|
|
|
|
|
|
|
See :ref:`syntax-coloring` to learn how to modify the color palette and to
|
|
|
|
|
see the available styles (use uppercased versions of the "roles" described
|
|
|
|
|
in that section).
|
|
|
|
|
|
2016-01-12 01:59:34 +00:00
|
|
|
|
If you pass the :option:`--no-color` option when running your command, all
|
|
|
|
|
``self.style()`` calls will return the original string uncolored.
|
2015-11-08 09:47:21 +00:00
|
|
|
|
|
2010-05-08 21:38:00 +00:00
|
|
|
|
Methods
|
|
|
|
|
-------
|
|
|
|
|
|
|
|
|
|
:class:`BaseCommand` has a few methods that can be overridden but only
|
|
|
|
|
the :meth:`~BaseCommand.handle` method must be implemented.
|
|
|
|
|
|
|
|
|
|
.. admonition:: Implementing a constructor in a subclass
|
|
|
|
|
|
2014-08-18 14:30:44 +00:00
|
|
|
|
If you implement ``__init__`` in your subclass of :class:`BaseCommand`,
|
|
|
|
|
you must call :class:`BaseCommand`’s ``__init__``::
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
2014-08-18 14:30:44 +00:00
|
|
|
|
class Command(BaseCommand):
|
|
|
|
|
def __init__(self, *args, **kwargs):
|
|
|
|
|
super(Command, self).__init__(*args, **kwargs)
|
|
|
|
|
# ...
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
2014-06-06 15:55:56 +00:00
|
|
|
|
.. method:: BaseCommand.add_arguments(parser)
|
|
|
|
|
|
|
|
|
|
Entry point to add parser arguments to handle command line arguments passed
|
|
|
|
|
to the command. Custom commands should override this method to add both
|
|
|
|
|
positional and optional arguments accepted by the command. Calling
|
|
|
|
|
``super()`` is not needed when directly subclassing ``BaseCommand``.
|
|
|
|
|
|
2010-05-08 21:38:00 +00:00
|
|
|
|
.. method:: BaseCommand.get_version()
|
|
|
|
|
|
2015-01-17 17:49:16 +00:00
|
|
|
|
Returns the Django version, which should be correct for all built-in Django
|
|
|
|
|
commands. User-supplied commands can override this method to return their
|
|
|
|
|
own version.
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
|
|
|
|
.. method:: BaseCommand.execute(*args, **options)
|
|
|
|
|
|
2015-01-17 17:49:16 +00:00
|
|
|
|
Tries to execute this command, performing system checks if needed (as
|
|
|
|
|
controlled by the :attr:`requires_system_checks` attribute). If the command
|
2016-01-12 17:28:55 +00:00
|
|
|
|
raises a :exc:`CommandError`, it's intercepted and printed to stderr.
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
2012-03-02 17:13:53 +00:00
|
|
|
|
.. admonition:: Calling a management command in your code
|
|
|
|
|
|
|
|
|
|
``execute()`` should not be called directly from your code to execute a
|
2016-01-12 23:01:29 +00:00
|
|
|
|
command. Use :func:`~django.core.management.call_command` instead.
|
2012-03-02 17:13:53 +00:00
|
|
|
|
|
2010-05-08 21:38:00 +00:00
|
|
|
|
.. method:: BaseCommand.handle(*args, **options)
|
|
|
|
|
|
|
|
|
|
The actual logic of the command. Subclasses must implement this method.
|
|
|
|
|
|
2015-10-06 19:08:15 +00:00
|
|
|
|
It may return a Unicode string which will be printed to ``stdout`` (wrapped
|
|
|
|
|
by ``BEGIN;`` and ``COMMIT;`` if :attr:`output_transaction` is ``True``).
|
|
|
|
|
|
2014-01-20 02:45:21 +00:00
|
|
|
|
.. method:: BaseCommand.check(app_configs=None, tags=None, display_num_errors=False)
|
2012-12-29 15:35:12 +00:00
|
|
|
|
|
2014-01-20 02:45:21 +00:00
|
|
|
|
Uses the system check framework to inspect the entire Django project for
|
2016-01-12 17:28:55 +00:00
|
|
|
|
potential problems. Serious problems are raised as a :exc:`CommandError`;
|
2014-01-20 02:45:21 +00:00
|
|
|
|
warnings are output to stderr; minor notifications are output to stdout.
|
|
|
|
|
|
2014-06-26 09:33:09 +00:00
|
|
|
|
If ``app_configs`` and ``tags`` are both ``None``, all system checks are
|
|
|
|
|
performed. ``tags`` can be a list of check tags, like ``compatibility`` or
|
|
|
|
|
``models``.
|
2014-01-20 02:45:21 +00:00
|
|
|
|
|
2010-05-08 21:38:00 +00:00
|
|
|
|
.. _ref-basecommand-subclasses:
|
|
|
|
|
|
2016-01-24 21:26:11 +00:00
|
|
|
|
``BaseCommand`` subclasses
|
|
|
|
|
--------------------------
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
|
|
|
|
.. class:: AppCommand
|
|
|
|
|
|
2013-12-24 22:43:47 +00:00
|
|
|
|
A management command which takes one or more installed application labels as
|
|
|
|
|
arguments, and does something with each of them.
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
2013-12-24 22:43:47 +00:00
|
|
|
|
Rather than implementing :meth:`~BaseCommand.handle`, subclasses must
|
|
|
|
|
implement :meth:`~AppCommand.handle_app_config`, which will be called once for
|
|
|
|
|
each application.
|
|
|
|
|
|
|
|
|
|
.. method:: AppCommand.handle_app_config(app_config, **options)
|
|
|
|
|
|
|
|
|
|
Perform the command's actions for ``app_config``, which will be an
|
|
|
|
|
:class:`~django.apps.AppConfig` instance corresponding to an application
|
|
|
|
|
label given on the command line.
|
|
|
|
|
|
2010-05-08 21:38:00 +00:00
|
|
|
|
.. class:: LabelCommand
|
|
|
|
|
|
2015-01-17 18:38:01 +00:00
|
|
|
|
A management command which takes one or more arbitrary arguments (labels) on
|
|
|
|
|
the command line, and does something with each of them.
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
|
|
|
|
Rather than implementing :meth:`~BaseCommand.handle`, subclasses must implement
|
|
|
|
|
:meth:`~LabelCommand.handle_label`, which will be called once for each label.
|
|
|
|
|
|
|
|
|
|
.. method:: LabelCommand.handle_label(label, **options)
|
|
|
|
|
|
2015-01-17 18:38:01 +00:00
|
|
|
|
Perform the command's actions for ``label``, which will be the string as
|
|
|
|
|
given on the command line.
|
2010-05-08 21:38:00 +00:00
|
|
|
|
|
|
|
|
|
Command exceptions
|
|
|
|
|
------------------
|
|
|
|
|
|
2016-01-12 17:28:55 +00:00
|
|
|
|
.. exception:: CommandError
|
2008-08-23 22:25:40 +00:00
|
|
|
|
|
2015-01-17 18:38:01 +00:00
|
|
|
|
Exception class indicating a problem while executing a management command.
|
2008-08-23 22:25:40 +00:00
|
|
|
|
|
2015-01-17 18:38:01 +00:00
|
|
|
|
If this exception is raised during the execution of a management command from a
|
|
|
|
|
command line console, it will be caught and turned into a nicely-printed error
|
|
|
|
|
message to the appropriate output stream (i.e., stderr); as a result, raising
|
|
|
|
|
this exception (with a sensible description of the error) is the preferred way
|
|
|
|
|
to indicate that something has gone wrong in the execution of a command.
|
2012-05-26 18:50:44 +00:00
|
|
|
|
|
2016-01-12 23:01:29 +00:00
|
|
|
|
If a management command is called from code through
|
|
|
|
|
:func:`~django.core.management.call_command`, it's up to you to catch the
|
|
|
|
|
exception when needed.
|