added optional celery support

[jayfk]

Uses the django:// BROKER_URL as default. One could argue that this might not be the best choice, because the current status is experimental <http://celery.readthedocs.org/en/latest/getting-started/brokers/django.html>_
. On the other hand, this is the only broker supported out of the box.

Any thoughts?

[pydanny]

While this is good, I've never been a fan of sticking Celery code into the __init__.py. Fortunately, there's another way to do things in modern Django: https://www.reddit.com/r/django/comments/3cjtu4/asynchronous_tasks_with_django_and_celery/cswllql

Would you be up for using that pattern instead?

[jayfk]

Yeah, that looks promising, I wasn't aware of that. I'll try to put something together tomorrow.

From a first quick glance I see two possible problems:

• Naming the app: Taskman sounds funny, but might confuses and isn't really obvious. Ideas?
• If a user chooses to not install celery, he'll have an empty folder in his project. One way to circumvent that would be to put celery.py into the conf/ folder. I'm not entirely sure if that is possible. Since celery.py can also contain tasks, we'd end up with code in the conf/ folder.

[burhan]

Regarding tasks, the best practice is to have a tasks.py in your app folder, this is also how celery discovers tasks; as per the documentation.

The only exception is tasks that are not tied to applications.

Taskman sounds good to me, to be honest.

[pydanny]

I'm not a giant fan of taskman for a app name, but everything about this suffices. FWIW, I'm not a fan of putting code into __init__.py, hence why I prefer this approach.

If this approach turns out to have problems, well then there is a reason why we consider cookiecutter-django bleeding edge. 😜

[pydanny]

I just changed taskman to taskapp. 😄

[mwdiers]

Hey, this is great, guys!

To restate here what I just posted on the Reddit:

I am using the celeryd init.d script provided by Celery and am not using force=True. This is the script in extra/generic-init.d/ I also follow the example in the docs.

I have not had any issues with autodiscovery. @sharedtask has worked perfectly for me, so I'm not sure what to tell you. There is no magic going on here. The line: app.autodiscover_tasks(lambda: settings.INSTALLED_APPS) should take care of this. It is supposed to check every app in settings.

[mwdiers]

Also, if there are project-level tasks, then I think tasksapp/tasks.py is the right place to put them, and not tasksapp/celery.py

That way, autodiscovery will pick them up properly.

[mwdiers]

One more note. I do not like the fact that one's settings module needs to be hard-coded into the celery config.

To work around this, I have a /config/celery_config.py. It contains just one line:

DJANGO_SETTINGS_MODULE = 'config.settings.production'

Then in my tasksapp/celery.py it have:

from config import celery_config

if not settings.configured:
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', celery_config.DJANGO_SETTINGS_MODULE)

This keeps local instance configuration is the right location.

[Rustem]

Then you couldn't use @shared_task decorator, which is usually more appropriate unless u r building a tiny app. Even if you will be able to use it by defining an import statement from .taskapp.celery import app in the proj/__init__.py, I think it just makes things much more compicated, rather than clean. celery.py is an entry point for celery app, nothing else, then lets maintain it same way as we do with manage.py.