id,summary,reporter,owner,description,type,status,component,version,severity,resolution,keywords,cc,stage,has_patch,needs_docs,needs_tests,needs_better_patch,easy,ui_ux 25848,"Django 1.9 breaks django_coverage_plugin, template coverage doesn't work",Ned Batchelder,nobody,"django_coverage_plugin (https://github.com/nedbat/django_coverage_plugin) does some tricky things to figure out which lines in your templates are being used, and which are not. It works great in Django 1.4 through 1.8. The template refactoring in 1.9 removed information the plugin needs to work. Preston Timmons has been very helpful in diagnosing the problem. He says the commit that broke it is: https://github.com/django/django/commit/55f12f8709f0604df7e1817a4c114ead1fb9a311 Preston's fuller assessment is: Yes, I'm supportive of that going into 1.9.1. Do you want to make a ticket in Trac? Please point to the commit where I broke things for you and mention how token.source used to give you access to the current template, whereas context.template.origin only gives you access to the parent. This was a change in private API, but you have an important use case that's worth making sure you can access the information you need. . A proper fix may include changing the semantics of context.bind_template. Alternatively, we could expose the current template on context.render_context. That attribute exists to store state during render invocations. . A less pleasant possibility may be to access `compiled_parent.origin.name` in the ExtendsNode render method. Or to grab the latest origin from the extends history with `context.render_context[ExtendsNode.context_key][-1]`. The IncludeNode would require a similar hack, but hopefully we can give you something better to work with than that. I'm very willing to work out a good solution, and do some of the work on the Django side if need be. It would be a shame if 1.9 had to sit out this feature of coverage.py. ",Cleanup/optimization,closed,Template system,1.9,Normal,fixed,,sdeibel@…,Accepted,1,0,0,0,0,0