docs: remove obsolete section "Automatic naming and relative imports" (…

…#6904)

Celery 5.0 dropped support for Python 2 and only supports Python 3.
Since Python 3 does not support old-style relative imports, the entire
section can be dropped.

Also remove a reference to the section above in
docs/django/first-steps-with-django.rst.

This change shall *not* be backported to Celery <5.0.

Fixes #6903.

Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>

docs/django/first-steps-with-django.rst

@@ -153,15 +153,6 @@ concrete app instance:
     You can find the full source code for the Django example project at:
     https://github.com/celery/celery/tree/master/examples/django/
 
-.. admonition:: Relative Imports
-
-    You have to be consistent in how you import the task module.
-    For example, if you have ``project.app`` in ``INSTALLED_APPS``, then you
-    must also import the tasks ``from project.app`` or else the names
-    of the tasks will end up being different.
-
-    See :ref:`task-naming-relative-imports`
-
 Extensions
 ==========
 

docs/userguide/tasks.rst

@@ -237,92 +237,6 @@ named :file:`tasks.py`:
     >>> add.name
     'tasks.add'
 
-.. _task-naming-relative-imports:
-
-Automatic naming and relative imports
--------------------------------------
-
-.. sidebar:: Absolute Imports
-
-    The best practice for developers targeting Python 2 is to add the
-    following to the top of **every module**:
-
-    .. code-block:: python
-
-        from __future__ import absolute_import
-
-    This will force you to always use absolute imports so you will
-    never have any problems with tasks using relative names.
-
-    Absolute imports are the default in Python 3 so you don't need this
-    if you target that version.
-
-Relative imports and automatic name generation don't go well together,
-so if you're using relative imports you should set the name explicitly.
-
-For example if the client imports the module ``"myapp.tasks"``
-as ``".tasks"``, and the worker imports the module as ``"myapp.tasks"``,
-the generated names won't match and an :exc:`~@NotRegistered` error will
-be raised by the worker.
-
-This is also the case when using Django and using ``project.myapp``-style
-naming in ``INSTALLED_APPS``:
-
-.. code-block:: python
-
-    INSTALLED_APPS = ['project.myapp']
-
-If you install the app under the name ``project.myapp`` then the
-tasks module will be imported as ``project.myapp.tasks``,
-so you must make sure you always import the tasks using the same name:
-
-.. code-block:: pycon
-
-    >>> from project.myapp.tasks import mytask   # << GOOD
-
-    >>> from myapp.tasks import mytask    # << BAD!!!
-
-The second example will cause the task to be named differently
-since the worker and the client imports the modules under different names:
-
-.. code-block:: pycon
-
-    >>> from project.myapp.tasks import mytask
-    >>> mytask.name
-    'project.myapp.tasks.mytask'
-
-    >>> from myapp.tasks import mytask
-    >>> mytask.name
-    'myapp.tasks.mytask'
-
-For this reason you must be consistent in how you
-import modules, and that is also a Python best practice.
-
-Similarly, you shouldn't use old-style relative imports:
-
-.. code-block:: python
-
-    from module import foo   # BAD!
-
-    from proj.module import foo  # GOOD!
-
-New-style relative imports are fine and can be used:
-
-.. code-block:: python
-
-    from .module import foo  # GOOD!
-
-If you want to use Celery with a project already using these patterns
-extensively and you don't have the time to refactor the existing code
-then you can consider specifying the names explicitly instead of relying
-on the automatic naming:
-
-.. code-block:: python
-
-    @app.task(name='proj.tasks.add')
-    def add(x, y):
-        return x + y
-
 .. _task-name-generator-info:
 
 Changing the automatic naming behavior