Over on the discord server we have had more than a few people excited and then confused about the new tasks framework coming in Django 6.0. The confusion mainly comes from mismatched expectations from those that have not been following the development of the feature and what precisely is available in 6.0. This has resulted in myself and others explaining that the main point of what is being introduced in 6.0 is for third-party packages to adopt the API and any normal devs would need a third-party package (eg django-tasks) to actually have a background task.
My suggestion for the 6.X release cycle (at least) would be to call out the need for a third-party package at the top of the docs page on tasks if a developer wants to have actual background tasks operated by a worker. This is likely a callout to django-tasks, but other packages could then be highlighted as they become available (I’m aware chancy has this as an unreleased feature)
As another mod/helper on the Django discord, a huge +1 to this…! It’s a big source of confusion. “What do you mean 6.0 introduces tasks but there’s no way of running them other than immediately?!”
As the author of django-tasks my opinion is naturally bias, but it has always been the intention that django.tasks was introduced in phases. The complexity in the initial PR in Django 6.0 alone is already quite high, and it’s not possible to include everything at once and keep the guarantees that Django has.
I can definitely see some value though in pointing users to the django-tasks repository for for the database and RQ backends: GitHub - RealOrangeOne/django-tasks: A reference implementation and backport of background workers and tasks in Django. However, it should also be documented that there’s not a need to install django-tasks. If someone isn’t using background tasks, there’s no need for it. If someone wants to use a 3rd-party backend not in django-tasks, again there’s no need to install it. So the wording needs to be quite specific (although I believe we have similar for 3rd-party cache backends).
I just want to clarify that I agree with the intention to introduce the feature in stages. That’s not the complaint at all from me. It’s the expectation that devs who haven’t been following likely thinking “Can I use django tasks like I use celery?” or similar.
In this case I think it’s important to highlight which third-party packages are required for background tasks.
I need to be able to start long-running tasks and have them run in the background, and when finished I’ll inform the user that it is complete and allow them to view the results. I see that Django 6 now has built-in support for background tasks. The documentation says that primarily for development and testing. My main question at this point is whether I should try to use this new API in Django 6 (and I presume figure out how to connect it to Celery or something similar,) or, should I follow a tutorial/guide written for Django 5 that shows how to connect to Celery without the dedicated background tasks API in Django 6?
I think not mentioning django-tasks in the documentation is going to keep these kind of questions coming in and would go so far as to say it’s may actively harm the adoption of tasks with more conservative developers.
One thing that needs to be balanced here I think are 2 different types of maintainer burden here. I recognise that what goes into the code & docs needs to be thought through and considered, however the second type is support related. Getting the same questions repeatedly is another burden when we could be removing the need for these questions with slightly more opinionated answers (especially when community consensus has agreed on a direction)
Agree we can call out django-tasks specifically somewhere, but I’m not sure what page our users are or are not reading. (E.g. did they make it to the community ecosystem page or not?)
Just noticed we need to update this in the ecosystem page to remove django-tasks from “exploratory” which is contradicting our messaging:
