Renamed AppConfig.setup to ready.

Thanks Jannis and Marc for the feedback.

Fixed #21717.

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.
         """

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):
         """

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
+    Subclasses can override this method to perform initialization tasks such
-    registering signals. It is called as soon as the registry is fully
+    as registering signals. It is called as soon as the registry is fully
     populated.
 
 Application registry

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() <django.apps.AppConfig.setup>` runs after the app
+:meth:`AppConfig.ready() <django.apps.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.

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.

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.