Description

What are you proposing? How should it be implemented?

I’d like to add django‑rq as an optional alternative to Celery in cookiecutter‑django.

This would not replace Celery. Instead, during project generation there would be a choice of task queue backend, for example:

• Celery
• django‑rq
• None

If django‑rq is selected, the template would:

• Add django-rq (and rq) to the dependencies.
• Add django_rq to INSTALLED_APPS and configure RQ_QUEUES, reusing the existing Redis settings when possible.
• Provide a standard worker command, for example python manage.py rqworker.
• Include a small example task and usage pattern that shows how to enqueue a job using django_rq.get_queue("default").enqueue(...).
• Optionally expose the django‑rq admin / dashboard if appropriate.

The Celery setup would remain as is, and users could still choose it instead.

Rationale

Why should this feature be implemented?

Many Django projects need background jobs for tasks like sending emails, processing uploads, or calling external APIs. Celery is very powerful, but it is also quite complex and comes with more moving parts.

django‑rq offers:

• A simpler mental model: jobs are just Python callables pushed into Redis, workers pull and run them.
• A natural fit if you already use Redis for caching or channels.
• Fewer components to configure since Redis doubles as both queue and storage for job metadata.
• Built in management and job monitoring via django‑rq’s admin and web views, without needing extra services like Flower or additional Django apps.

For a lot of cookiecutter‑django users, django‑rq is “enough queue” while being easier to understand and maintain than Celery. Making it a first‑class, opt‑in option would give teams a practical choice between:

• Celery for advanced or high scale setups.
• django‑rq for simpler, Redis based workloads.

Existing projects that rely on Celery would not be affected, since this would only apply to new projects that choose django‑rq at generation time.