Merge branch 'master' into 3.1

celery/bin/base.py

@@ -452,10 +452,14 @@ class Command(object):
             sym = import_from_cwd(app)
         if isinstance(sym, ModuleType):
             try:
-                return sym.app
+                found = sym.app
+                if isinstance(found, ModuleType):
+                    raise AttributeError()
             except AttributeError:
                 try:
-                    return sym.celery
+                    found = sym.celery
+                    if isinstance(found, ModuleType):
+                        raise AttributeError()
                 except AttributeError:
                     if getattr(sym, '__path__', None):
                         try:
@@ -468,6 +472,8 @@ class Command(object):
                         if isinstance(suspect, Celery):
                             return suspect
                     raise
+            else:
+                return found
         return sym
 
     def symbol_by_name(self, name):

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

@@ -62,7 +62,7 @@ so that the ``@shared_task`` decorator (mentioned later) will use it:
 
     from __future__ import absolute_import
 
-    from .celery import app as celery_app
+    from .celery import app
 
 Note that this example project layout is suitable for larger projects,
 for simple projects you may use a single contained module that defines

docs/django/index.rst

@@ -11,5 +11,3 @@
     :maxdepth: 2
 
     first-steps-with-django
-    unit-testing
-

docs/django/unit-testing.rst

@@ -1,56 +0,0 @@
-================
- Unit Testing
-================
-
-Testing with Django
--------------------
-
-The first problem you'll run in to when trying to write a test that runs a
-task is that Django's test runner doesn't use the same database as your celery
-daemon is using. If you're using the database backend, this means that your
-tombstones won't show up in your test database and you won't be able to
-get the return value or check the status of your tasks.
-
-There are two ways to get around this. You can either take advantage of
-``CELERY_ALWAYS_EAGER = True`` to skip the daemon, or you can avoid testing
-anything that needs to check the status or result of a task.
-
-Using a custom test runner to test with celery
-----------------------------------------------
-
-If you're going the ``CELERY_ALWAYS_EAGER`` route, which is probably better than
-just never testing some parts of your app, a custom Django test runner does the
-trick. Celery provides a simple test runner, but it's easy enough to roll your
-own if you have other things that need to be done.
-http://docs.djangoproject.com/en/dev/topics/testing/#defining-a-test-runner
-
-For this example, we'll use the ``djcelery.contrib.test_runner`` to test the
-``add`` task from the :ref:`guide-tasks` examples in the Celery
-documentation.
-
-To enable the test runner, set the following settings:
-
-.. code-block:: python
-
-    TEST_RUNNER = 'djcelery.contrib.test_runner.CeleryTestSuiteRunner'
-
-Then we can put the tests in a ``tests.py`` somewhere:
-
-.. code-block:: python
-
-    from django.test import TestCase
-    from myapp.tasks import add
-
-    class AddTestCase(TestCase):
-
-        def testNoError(self):
-            """Test that the ``add`` task runs with no errors,
-            and returns the correct result."""
-            result = add.delay(8, 8)
-
-            self.assertEqual(result.get(), 16)
-            self.assertTrue(result.successful())
-
-
-This test assumes that you put your example ``add`` task in ``maypp.tasks``
-so adjust the import for wherever you put the class.

examples/django/proj/__init__.py

@@ -2,4 +2,4 @@ from __future__ import absolute_import
 
 # This will make sure the app is always imported when
 # Django starts so that shared_task will use this app.
-from .celery import app as celery_app
+from .celery import app

requirements/pkgutils.txt

@@ -1,3 +1,5 @@
+setuptools>=1.3.2
+wheel
 paver
 flake8
 flakeplus