django.core.management.execute_manager is deprecated #59
django.core.management.execute_manager is deprecated #59
Conversation
I'm fairly certain this will take a big chunk out of this issue |
Here's the relevant change notes: |
Just FYI, if you aren't on Celery 3.x yet this change will cause some tasks not to be registered. I think playdoh is still on Celery 2.5.x which doesn't officially support django 1.5+. |
if current_settings is None: | ||
_not_setup() | ||
execute_manager(current_settings) | ||
argv = argv or sys.argv | ||
execute_from_command_line(argv) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks fine for newer Djangos but I guess it will break in older ones. Do we need to support both?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"newer Djangos" :)
That's 1.4 we're talking about here. They're about to release 1.7 soon :)
I doubt anybody on django 1.3 is going to upgrade their funfactory to the latest and greatest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's fine by me. I don't know of anyone tied to 1.3 who would want to upgrade playdoh independently.
@rlr interesting. What needs to change so that these Celery 2.5 continues to work? |
On SUMO, we upgraded to Celery 3.0.24 and then we were able to land a change similar to this: |
So, is the trick that you have to call @rlr What change is needed to this patch to make it work with Celery 2.5? |
@rlr ping ^ |
@peterbe I didn't look into fixing Celery 2.5, I ended up upgrading to Celery 3.0.x |
Celery 2.5.x is very old |
@rlr so, to move forward, can you put Celery 3.0.x into playdoh-lib and test it with playdoh? |
Or perhaps @willkg ? |
Input doesn't use playdoh-lib anymore. I'm not sure I have time to do this, either. @Osmose or @pmclanahan: Can either of you upgrade playdoh-lib to a more recent celery? Do either of you use celery? |
I do in basket, but basket isn't using playdoh-lib. Basket is stuck on version 2.5.x of celery however because the 3.x line comes with a new compiled dependency (billiard) that I've not had the time to work with Ops to install. This would also make it tough to add to playdoh-lib as forcing people to deal with that mess in order to get a newer version of something else we provide (e.g. Django) could be nasty. I'd move more in the direction of removing Celery as something playdoh-lib provides. It seems like something that few new projects would need. If you do need it then you've got a lot of setup and infra work to do anyway, and installing celery should be the least of it. |
+1 to @pmclanahan's suggestion to remove celery from playdoh-lib. |
It looks like maybe the C extension for billiard isn't technically required. So we could probably get away with this. I'm still of the opinion that celery doesn't belong here though. For the purposes of this PR however we may be able to just upgrade. We'll need to look at the upgrade docs though to see what sites might have to do before upgrading from 2.5.x to 3.x. |
I originally thought there that billiard needed to be compiled, but then @rlr upgraded celery on SUMO and Input without compiling billiard. So I was wrong on that (or things changed--can't tell for sure). Here's the PR for upgrading celery in Input: mozilla/fjord#231 |
Yeah. On further investigation it's just slightly less featureful. We probably don't need those features anyway. The C extension is a fork of the stdlib C bits of multiprocessing. So it falls back to that.Sent from my mobile. Please excuse my brevity. |
FYI reps.m.o and mozillians.org are both heavy celery eaters. I'm happy to try and test things on these projects if we need to. |
So, if I've read this correctly, @pmclanahan is volunteering to remove all things celery from playdoh-lib? Is that right? I love celery and I use it for some personal projects but none of the 6-7 Mozilla playdoh-based projects use Celery. Being able to land this patch would be nice too :) |
@peterbe I do think it should be removed, but that's likely a whole lotta scope creep for this PR. Since we all seem agreed that I was wrong and that we can indeed upgrade to celery 3.0.x, perhaps the path of least resistance is to do that for now. But I'm with you that we should do whatever is best and fastest to get this landed. Also yes, I will take on removing celery if that's what we wanna do. |
@pmclanahan because I'm not using Celery I'm perhaps too biased towards removing it. |
@pmclanahan sorry to nag but have we made any progress on getting rid of Celery from playdoh and playdoh-lib? |
I still think the path of least resistance is to upgrade celery for now. Also no, I've not found time to work on it yet. |
I've failed to act on this. Let's just remove celery from playdoh(-lib). People who need/use celery have almost certainly upgraded independently, and we need to land this change. What's the risk if we just merge this as-is? |
…er-is-deprecated django.core.management.execute_manager is deprecated
@kumar303 @andymckay @robhudson r?
This change makes the deprecation warning go away when using funfactory in django 1.5.
tox still passes.
I tested this in my airmozilla project with Django 1.6 and it worked.
Also, I checked that you can still override stuff on the command line. E.g.
./manage.py shell --settings=airmozilla.settings_copy
and it picked it up correctly.