'Command' object has no attribute 'stderr', now in django.core.management.base.BaseCommand.check

[cpbotha]

Similar to issue https://code.djangoproject.com/ticket/19665 the new Django check logic is triggering the following exception in Django 1.7rc2 with celery 3.1.13 and djcelery 3.1.10:

./manage.py celery
Traceback (most recent call last):
  File "./manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/home/cpbotha/.virtualenvs/test/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 385, in execute_from_command_line
    utility.execute()
  File "/home/cpbotha/.virtualenvs/test/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 377, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/cpbotha/.virtualenvs/test/local/lib/python2.7/site-packages/djcelery/management/commands/celery.py", line 22, in run_from_argv
    self.validate()
  File "/home/cpbotha/.virtualenvs/test/local/lib/python2.7/site-packages/django/core/management/base.py", line 361, in validate
    return self.check(app_configs=app_configs, display_num_errors=display_num_errors)
  File "/home/cpbotha/.virtualenvs/test/local/lib/python2.7/site-packages/django/core/management/base.py", line 415, in check
    self.stderr.write(msg)
AttributeError: 'Command' object has no attribute 'stderr'

Similar to the previous bug, self.stderr is being referenced before it has been initialized. I ported the fix from that bug (which also exists in current Django master), the diff is attached.

[Tim Graham]

It looks to me like the call to validate() was added in ​https://github.com/celery/django-celery/commit/622f39b6f15e33fb37d443f32e0544b2648a57c9 to initialize app loading. Seems like this could (should?) be replaced by django.setup() in Django 1.7. I'm not quit sure if we should make this change or ask celery to do so. Are you a developer for that project or do you know if there's a ticket in their tracker?

That said, if we need to make this change for backwards compatibility, it should have a test.

[cpbotha]

I am not a developer on celery.

1. The change to Django does not hurt the default case, but enables Django to give the actually relevant validation feedback instead of actually just raising an unrelated exception.

2. Another option would be for Django 1.7 to complain about the use of validate(), but I don't know enough to comment on that.

What is the best course of action now?

[cpbotha]

It looks like the main celery software is already using django.setup() -- however, django-celery is not. The documentation there is unclear as to what the current role of django-celery is. I've logged a bug there with more detail: ​https://github.com/celery/celery/issues/2174

[Brian May]

I think this bug may have accidentally been diverted on the wrong track.

django/core/management/init.py line 354 already has a call to django.setup(), we do we need to call it again?

        if settings.configured:                                                  
            django.setup()                                                       

[Brian May]

I don't understand why ​https://github.com/celery/django-celery/commit/622f39b6f15e33fb37d443f32e0544b2648a57c9 was made, django-celery version 2.5.5 (before this change AFAIK) seemed to work fine with DJango 1.7 RC 1 (I tested it several days ago), suspect the change could be reverted.

Will do more tests to try an confirm this.

[Brian May]

Also see ​https://github.com/celery/django-celery/issues/253

[Tim Graham]

I think validate() was added as a hack to initialize app loading in Django < 1.7 and I think it shouldn't be called in 1.7+.

[Brian May]

Ok, finally able to reproduce this error.

No error will occur unless Django finds potential problems with the databases, and as there were none in my project, I wasn't able to reproduce this at first.

I agree with the resolution made by timo in comment9. This is not a Django bug. Unless there is documentation that says calling validate() here is ok, I doubt it.

I have reported this issue here: ​https://github.com/celery/django-celery/issues/336

Thanks.

[Brian May]

The other issue, concerning the relevance of django-celery, now reported against django-celery here: ​https://github.com/celery/django-celery/issues/335 (previous report was against celery).