diff --git a/django/apps/base.py b/django/apps/base.py index 1aa5c29fd2..47f0a57711 100644 --- a/django/apps/base.py +++ b/django/apps/base.py @@ -159,7 +159,7 @@ class AppConfig(object): models_module_name = '%s.%s' % (self.name, MODELS_MODULE_NAME) self.models_module = import_module(models_module_name) - def setup(self): + def ready(self): """ - Override this method in subclasses to run setup code. + Override this method in subclasses to run code when Django starts. """ diff --git a/django/apps/registry.py b/django/apps/registry.py index 3cd6d480f1..db75f999c5 100644 --- a/django/apps/registry.py +++ b/django/apps/registry.py @@ -105,7 +105,7 @@ class Apps(object): self.ready = True for app_config in self.get_app_configs(): - app_config.setup() + app_config.ready() def check_ready(self): """ diff --git a/docs/ref/applications.txt b/docs/ref/applications.txt index 38bf474371..ed3f33a2cc 100644 --- a/docs/ref/applications.txt +++ b/docs/ref/applications.txt @@ -175,10 +175,10 @@ Methods ``model_name``. Raises :exc:`~exceptions.LookupError` if no such model exists. ``model_name`` is case-insensitive. -.. method:: AppConfig.setup() +.. method:: AppConfig.ready() - Subclasses can override this method to perform setup tasks such as - registering signals. It is called as soon as the registry is fully + Subclasses can override this method to perform initialization tasks such + as registering signals. It is called as soon as the registry is fully populated. Application registry diff --git a/docs/ref/signals.txt b/docs/ref/signals.txt index 2e9f6ccea6..5c3d544c5a 100644 --- a/docs/ref/signals.txt +++ b/docs/ref/signals.txt @@ -355,7 +355,7 @@ been defined and registered with Django's model system. Django uses this signal internally; it's not generally used in third-party applications. Since this signal is sent during the app registry population process, and -:meth:`AppConfig.setup() ` runs after the app +:meth:`AppConfig.ready() ` runs after the app registry is fully populated, receivers cannot be connected in that method. One possibility is to connect them ``AppConfig.__init__()`` instead, taking care not to import models or trigger calls to the app registry. diff --git a/docs/releases/1.7.txt b/docs/releases/1.7.txt index af0acd7152..b559445e7c 100644 --- a/docs/releases/1.7.txt +++ b/docs/releases/1.7.txt @@ -74,7 +74,7 @@ attach configuration data to applications. Improvements thus far include: * Applications can run code at startup, before Django does anything else, with - the :meth:`~django.apps.AppConfig.setup` method of their configuration. + the :meth:`~django.apps.AppConfig.ready` method of their configuration. * It is possible to omit ``models.py`` entirely if an application doesn't have any models. diff --git a/docs/topics/signals.txt b/docs/topics/signals.txt index 9a311cd506..ee6fb847a2 100644 --- a/docs/topics/signals.txt +++ b/docs/topics/signals.txt @@ -142,14 +142,14 @@ Now, our ``my_callback`` function will be called each time a request finishes. In practice, signal handlers are usually defined in a ``signals`` submodule of the application they relate to. Signal receivers are - connected in the :meth:`~django.apps.AppConfig.setup` method of your + connected in the :meth:`~django.apps.AppConfig.ready` method of your application configuration class. If you're using the :func:`receiver` decorator, simply import the ``signals`` submodule inside - :meth:`~django.apps.AppConfig.setup`. + :meth:`~django.apps.AppConfig.ready`. .. versionchanged:: 1.7 - Since :meth:`~django.apps.AppConfig.setup` didn't exist in previous + Since :meth:`~django.apps.AppConfig.ready` didn't exist in previous versions of Django, signal registration usually happened in the ``models`` module.