All settings are now in lowercase, and most of them have been renamed.
When loading settings the loader will look at the settings in the config
and decide if it's using old or new settings.
The settings will autmatically convert between old and new settings keys, depending
on the format the settings is in.
- It's not legal to mix new setting names and old setting names, that is unless
the setting have two alternatives (old and new).
An ImproperlyConfigured exceptions is rasised in this case, with help telling
user exactly how to fix the problem.
- To support loading configuration from Django settings a new ``namespace``
argument has been added to ``Celery`` and ``config_from_object``.
This can be used from Django::
app = Celery()
app.config_from_object('django.conf:settings', namespace='CELERY_')
# settings.py:
CELERY_BROKER_URL = 'amqp://'
CELERY_TASK_PROTOCOL = 2
CELERY_TASK_ALWAYS_EAGER = True
Or other apps wanting a prefix for some reason::
app = Celery(namespace='celery_')
app.conf.celery_task_always_eager = True
app.conf.celery_task_routes = {'proj.tasks.add': 'math.yo'}
- Initial configuration directly on the app object is now lazy!
You can set keys on an unfinalized app, without causing the tasks
or the rest of the app to be evaluated:
app = Celery()
app.conf.update(
task_default_delivery_mode=1,
task_default_queue='default',
task_default_exchange='default',
task_default_routing_key='default',
)
app.conf.task_always_eager = True
assert not app.configured # <-- still not finalized
app.config_from_object('celeryconfig')
assert not app.configured # <-- even now
app.finalize()
assert app.finalized # <-- but now we are
# and the config done first remains, unlike older versions of Celery.
assert app.conf.task.default_queue == 'default'
app.config_from_object(object())
# but calling config_from_* again will reset everything.
assert app.conf.task_default_queue == 'celery'
- ``config_from_*`` methods no longer override configuration set manually
before the app was finalized.
But calling again after the app is finalized, will clean out old
configuration.
With 'kombu.transport.django.KombuAppConfig' in INSTALLED_APPS,
running any manage.py command throws:
ImportError: No module named KombuAppConfig
It is fixed by changing 'kombu.transport.django.KombuAppConfig' to 'kombu.transport.django'
If `app.autodiscover_tasks()` is called without a packages argument, the
Django fixup will now take the list of modules from the app config registry.
Closes#2596
Ask Solem
Adam Renberg
Evgeniy
wyc
Zhaorong Ma
dongweiming