Repository navigation
Version 1.4 seems to break when django.templates.backends has not been initialized #32
Description
Activity
I can only reproduce it in one case where we're not using a management command, so this doesn't look like a complete show-stopper. Still looking at it
I observe such behavior even if running with
coverage run manage.py test(Django 1.6 project migrating to 1.8)I just wanted to add that we've just recently started to experience this issue...
(backend) [17:43:43] gary:backend git:(dev*) $ coverage run ./manage.py test -v 2 Coverage.py warning: Disabling plugin 'django_coverage_plugin.DjangoTemplatePlugin' due to an exception: Traceback (most recent call last): File "/home/gary/dev/envs/backend/local/lib/python2.7/site-packages/coverage/control.py", line 476, in _should_trace_internal file_tracer = plugin.file_tracer(canonical) File "/home/gary/dev/envs/backend/local/lib/python2.7/site-packages/django_coverage_plugin/plugin.py", line 158, in file_tracer self.debug_checked = check_debug() File "/home/gary/dev/envs/backend/local/lib/python2.7/site-packages/django_coverage_plugin/plugin.py", line 56, in check_debug if not hasattr(django.template.backends, "django"): AttributeError: 'module' object has no attribute 'backends'We're currently running:
coverage==4.3.4 django-coverage-plugin==1.4 Django==1.9Any idea how we can resolve this issue and move forward?
Thanks
Ned just released
django-coverage-plugin==1.4.1which should address the problems dealing wit deferred initialization of the backends.Please check it out and let us know if it works for you.
@PamelaM Thank you for getting back to me, I appreciate your response.
Since upgrading to
django-coverage-plugin==1.4.1we're now experiencing the following issue.(backend) [8:55:09] gary:backend git:(dev*) $ pip freeze | grep coverage coverage==4.3.4 django-coverage-plugin==1.4.1 (backend) [8:55:14] gary:backend git:(dev*) $ coverage run ./manage.py test -v 2 Coverage.py warning: Disabling plugin 'django_coverage_plugin.DjangoTemplatePlugin' due to an exception: Traceback (most recent call last): File "/home/gary/dev/envs/backend/local/lib/python2.7/site-packages/coverage/control.py", line 476, in _should_trace_internal file_tracer = plugin.file_tracer(canonical) File "/home/gary/dev/envs/backend/local/lib/python2.7/site-packages/django_coverage_plugin/plugin.py", line 163, in file_tracer self.debug_checked = check_debug() File "/home/gary/dev/envs/backend/local/lib/python2.7/site-packages/django_coverage_plugin/plugin.py", line 67, in check_debug for engine in django.template.engines.all(): File "/home/gary/dev/envs/backend/local/lib/python2.7/site-packages/django/template/utils.py", line 110, in all return [self[alias] for alias in self] File "/home/gary/dev/envs/backend/local/lib/python2.7/site-packages/django/template/utils.py", line 101, in __getitem__ engine = engine_cls(params) File "/home/gary/dev/envs/backend/local/lib/python2.7/site-packages/django/template/backends/django.py", line 31, in __init__ options['libraries'] = self.get_templatetag_libraries(libraries) File "/home/gary/dev/envs/backend/local/lib/python2.7/site-packages/django/template/backends/django.py", line 49, in get_templatetag_libraries libraries = get_installed_libraries() File "/home/gary/dev/envs/backend/local/lib/python2.7/site-packages/django/template/backends/django.py", line 132, in get_installed_libraries for app_config in apps.get_app_configs()) File "/home/gary/dev/envs/backend/local/lib/python2.7/site-packages/django/apps/registry.py", line 137, in get_app_configs self.check_apps_ready() File "/home/gary/dev/envs/backend/local/lib/python2.7/site-packages/django/apps/registry.py", line 124, in check_apps_ready raise AppRegistryNotReady("Apps aren't loaded yet.") AppRegistryNotReady: Apps aren't loaded yet.Unfortunately it seems as if our best option at this point is to downgrade to
django-coverage-plugin==1.3.1I'll keep plugging away this weekend. I can see where you're getting the error, now I just need to figure out what my integration test environment is doing differently than your environment (since I'm not getting that error).
It's probably time to step back and rethink every part of the startup process. I'll probably also remove support for DJ 1.7 and earlier - if only to simplify the plugin.
Clearly, there are a number of variables. I see that you're running "Python==2.7.(something)". I'll assume you're still on "Django==1.9" and focus on that.
Thanks @PamelaM.
You're correct. The error is occurring within our backend environment which is setup as
(backend) [9:38:06] gary:backend git:(dev*) $ python --version Python 2.7.12 (backend) [9:38:36] gary:backend git:(dev*) $ pip freeze | grep Django Django==1.9 (backend) [9:38:41] gary:backend git:(dev*) $ pip freeze | grep coverage coverage==4.3.4 django-coverage-plugin==1.4.1 (backend) [9:38:47] gary:backend git:(dev*) $Thanks again. Please let me know if you need any additional information.
@PamelaM Sorry for the delay in my response.
Any idea how I would be able to pull in that PR through pip? I have tried the following command with your PR commit
pip install git+https://github.com/nedbat/django_coverage_plugin.git@4df203a0908ac638f6c6da2b2e53096eb29506e8with no luck.Would love to test out that PR for you.
@garyayo Use the following:
pip install https://codeload.github.com/nedbat/django_coverage_plugin/zip/4df203a0908ac638f6c6da2b2e53096eb29506e8Note that if you already have django-coverage-plugin 1.4.1 installed pip won't upgrade to the new code because it's the same version number.
Reacted by Gary AleixoVery excellent! Thank you @clokep!
@PamelaM I've very happy to say that my issue appears to have been resolved!
(backend) [9:10:42] gary:backend git:(dev*) $ pip install https://codeload.github.com/nedbat/django_coverage_plugin/zip/4df203a0908ac638f6c6da2b2e53096eb29506e8 Collecting https://codeload.github.com/nedbat/django_coverage_plugin/zip/4df203a0908ac638f6c6da2b2e53096eb29506e8 Downloading https://codeload.github.com/nedbat/django_coverage_plugin/zip/4df203a0908ac638f6c6da2b2e53096eb29506e8 | 30kB 942kB/s Requirement already satisfied: Django>=1.4 in /home/gary/dev/envs/backend/lib/python2.7/site-packages (from django-coverage-plugin==1.4.2) Requirement already satisfied: coverage>=4.0 in /home/gary/dev/envs/backend/lib/python2.7/site-packages (from django-coverage-plugin==1.4.2) Requirement already satisfied: six>=1.4.0 in /home/gary/dev/envs/backend/lib/python2.7/site-packages (from django-coverage-plugin==1.4.2) Installing collected packages: django-coverage-plugin Running setup.py install for django-coverage-plugin ... done Successfully installed django-coverage-plugin-1.4.2 (backend) [9:13:54] gary:backend git:(dev*) $ pip freeze | grep coverage coverage==4.3.4 django-coverage-plugin==1.4.2 (backend) [9:14:00] gary:backend git:(dev*) $ pip freeze | grep Django Django==1.9 (backend) [9:11:11] gary:backend git:(dev*) $ coverage run ./manage.py test v4.test.test_scheduler -v 2 Creating test database for alias 'default'Thanks for all the hard work.
Excellent! Thanks for checking!
Fixed by version 1.4.2
This is clearly a bug caused by my recent PR.
I'll work though a fix PR in the next two days.
Because of the chicken-and-egg issues of starting, I think the need for a test_project that can be used for full integration testing via subprocess calls is even more vital. There are too many "shenanigans" involved with getting coverage/django startup initialization order reversed and re-run during the current test process.