Celery 4.0 and the future of django-celery project
See original GitHub issueHi guys! So celery v4.0 has been released, and according to the new docs, there are dedicated Django extensions that seem to overlap with, if not deprecate, this project for newer versions of Python and Django.
Will this be the direction moving forward? Specifically the django-celery
package should only be used if one is using Django<=1.8 with Celery<=3.1, and one should update libraries whenever possible.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:10
- Comments:15 (4 by maintainers)
Top Results From Across the Web
What's new in Celery 4.0 (latentcall)
This version introduces a brand new task message protocol, the first major change to the protocol since the beginning of the project. The...
Read more >Breaking Down Celery ≥4.x With Python and Django
Let's see how we can configure the same celery task into our Django project. Ideally, you should create a new virtual environment for...
Read more >Asynchronous Tasks With Django and Celery - Real Python
In this tutorial, you'll learn how to integrate Celery and Django using Redis as a message broker. You'll refactor the synchronous email ...
Read more >Celery 4 Periodic Task in Django - Medium
After experimenting with Ubuntu 16.04 LTS, Python 3.6.1, Django 1.11.2, Celery 4.0.2, and Redis 3.0.6, I finally grasped how it works.
Read more >Celery 4 with Django on Ubuntu 18.04 - WILL & SKILL
In this tutorial we will set up Celery in our Django project in a few steps and make it run as a Daemon...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Actually the feature that matters most to me is the ability to create periodic tasks via the admin interface. For many use cases, specifying the schedules in
settings.py
is sufficient.However, in my use case, where the same concept of a particular task is shared across different clients, departments, or organizations, but each has a different schedule and/or has different args/kwargs passed into the same task function, and said schedules may change on a whim, manually editing the
settings.py
file is not sustainable.Moreover, I can sleep more soundly if I give support personnel limited access to the admin interface to edit those tasks VS giving them shell access and let them edit production code. IMO, that alone is enough to make this a must-have package instead of an optional one. Kind of like pytz is to Django.
Anyway, thanks for the clarification! At least now we know that deprecation of this project is indeed the direction. I will start using the new packages when I get the chance.
@arcivanov I understand what you meant