django-tasks is an accepted Enhancement Proposal to bring background workers into Django itself (as django.tasks). Introducing both a common API contract for developers and library authors (eg django.core.cache), but also a production-grade ORM-based worker and queue.
I gave a talk at Djangocon Europe last month introducing it:
Now, I need your help testing it, finding the issues, and adding features. The aim is to get it merged into Django 5.2 (April 2025, but the merge deadline is December 2024), and thereās a lot still to do between now and then.
Give it a try, see how it works, and let me know what you think!
Hello! I saw your video and decided to come here to ask about it. Are you looking to eventually be able to interface with Celery or similar worker providers like RQ using the consistent django-tasks (or similarly named) API? I wasnāt exactly sure from the video whether thatās the ultimate goal is to interface with the existing systems or to simply replace most use-cases with a DB-backed system.
Iād like interops between existing implementations, yes. When and who writes them is still TBC. Thereās a Celery backend in progress.
These will absolutely be in Django core, as itās too much maintenance burden.
The DB backend will definitely be in Django core. Redis might come later to core, but thatās not my decision to make. django-tasks will likely live on to contain the components which donāt make sense in Django core, and as a testing ground before integrating.
The first PR, implementing the core API for background workers is up for review !
The notable omission is the database worker. This exists in django-tasks, but in the interest of easier review, isnāt in the first PR. Itāll come later, once the core is merged.
thank you very much for the great work. Meanwhile, when the ticket is not yet merged, my question is, can I start using django-tasks as a separate module and later remove django-tasks when it is available as part of the Djangoās core without any code changes?
Cheers,
Alex
āwithout any code changesā is a very strong phrase. No, you canāt do it without any, but it should be minimal at best. As an application developer, it should be a case of swapping out the task backend in TASKS, and changing where you import the task decorator from. Everything else should ājust workā
Exactly how a project will behave with both installed, I donāt know. In theory the APIs are the same, so assuming they have the same backend, each packageās task decorator shouldnāt conflict.
!