From bb8ec71f61066587aa3a8feb0aedab213422775a Mon Sep 17 00:00:00 2001 From: Aymeric Augustin Date: Tue, 24 Dec 2013 23:43:47 +0100 Subject: Updated the AppCommand API to support apps without a models module. --- docs/howto/custom-management-commands.txt | 33 +++++++++++++++++++++++-------- docs/internals/deprecation.txt | 2 ++ docs/releases/1.7.txt | 4 ++++ 3 files changed, 31 insertions(+), 8 deletions(-) (limited to 'docs') diff --git a/docs/howto/custom-management-commands.txt b/docs/howto/custom-management-commands.txt index 2325e32ac2..4f95838760 100644 --- a/docs/howto/custom-management-commands.txt +++ b/docs/howto/custom-management-commands.txt @@ -313,17 +313,34 @@ BaseCommand subclasses .. class:: AppCommand -A management command which takes one or more installed application -names as arguments, and does something with each of them. +A management command which takes one or more installed application labels as +arguments, and does something with each of them. -Rather than implementing :meth:`~BaseCommand.handle`, subclasses must implement -:meth:`~AppCommand.handle_app`, which will be called once for each application. +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. + +.. versionchanged:: 1.7 + + Previously, :class:`AppCommand` subclasses had to implement + ``handle_app(app, **options)`` where ``app`` was a models module. The new + API makes it possible to handle applications without a models module. The + fastest way to migrate is as follows:: -.. method:: AppCommand.handle_app(app, **options) + def handle_app_config(app_config, **options): + if app_config.models_module is None: + return # Or raise an exception. + app = app_config.models_module + # Copy the implementation of handle_app(app_config, **options) here. - Perform the command's actions for ``app``, which will be the - Python module corresponding to an application name given on - the command line. + However, you may be able to simplify the implementation by using directly + the attributes of ``app_config``. .. class:: LabelCommand diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt index 29a68ff0c1..29f7df53ae 100644 --- a/docs/internals/deprecation.txt +++ b/docs/internals/deprecation.txt @@ -179,6 +179,8 @@ these changes. * The model and form ``IPAddressField`` will be removed. +* ``AppCommand.handle_app()`` will no longer be supported. + * FastCGI support via the ``runfcgi`` management command will be removed. Please deploy your project using WSGI. diff --git a/docs/releases/1.7.txt b/docs/releases/1.7.txt index 5aba3ca096..2c3e3f217d 100644 --- a/docs/releases/1.7.txt +++ b/docs/releases/1.7.txt @@ -593,6 +593,10 @@ methods are only referring to fields or other items in ``model._meta``. App-loading changes ~~~~~~~~~~~~~~~~~~~ +Subclasses of :class:`~django.core.management.AppCommand` must now implement a +:meth:`~django.core.management.AppCommand.handle_app_config` method instead of +``handle_app()``. This method receives an :class:`~django.apps.AppConfig` instance. + Since :setting:`INSTALLED_APPS` now supports application configuration classes in addition to application modules, you should review code that accesses this setting directly and use the app registry (:attr:`django.apps.apps`) instead. -- cgit v1.3