calebsmith/django-template-debug

A small collection of template tags for debugging and introspecting templates

django-template-debug's Issues

Add an easy way to render a template string

While within a set trace, it would be nice to easily render some input as a template interactively. In other words, the set trace naturally gives a Python interface to the template context and makes some utilities, such as details() available, but there is a small disconnect of then expressing that work again in the template file and waiting for a refresh, which is vaguely a "compile time" approach.

Instead, it seems very useful to me to have something like a render function that just renders an arbitrary string as a template, using the current template context

Python3.3 compatibility

basestring usage inside debug_tags.py prevent work with python3.3 with new django 1.5

Add a find() tag, that finds the filename and line number for a function's definition

Improve/verify python3 compatibility of utils.is_valid_in_template

The value.im_func.func_code.co_arguments call might only function properly in python 2. A targeted test is needed.

Make django template debug Python 3 compatible

__pycache__

Hi,

very nice tool, thanks.

The distribution package has pycache dir in it. that breaks"python setup.py bdist_egg that in turn is used by buildout. Please fix the package!

sandro

Make details() values more friendly where possible

Common django classes such as ManyRelatedManager should return a similarly named string rather than the repr which is a bit long

Remove filename/line number introspection tools for now.

The tools for introspecting file name and line number of callables is difficult to test, and not easy to port to Python3. In order to reduce duplication of effort, this new feature that hasn't received a ton of interest is being removed for now.
N. B. - The filename/line number introspection tools/tags were never part of a released version.

The plan is to eventually replace these with similar tools in @ironfroggy's tracerlib.

details() uses a blanket except, which could mask problems that should raise exceptions

Improve test coverage

Two known points are the get_attributes utility function and making the get_details utility function a more targeted unit test. After some refactoring, the latter became more of an integration test.

Make a tag like details, but only showing the list of available attributes (and not their values)

This would essentially be the same thing as taking the dictionary returned by the details tag and using .keys(). Thiis tag provides the user with cleaner output, much like dir() in a python shell.

As an added benefit, this feature should help factor out the logic in get_details that excludes attributes that are not available inside of templates.

Error with ipdb and py.test: AttributeError: DontReadFromInput instance has no attribute 'encoding'

I am seeing the following error with py.test when template_debug is included.

  File "venv/lib/python2.7/site-packages/template_debug/templatetags/debug_tags.py", line 8, in <module>
    import ipdb as pdb
  File "venv/lib/python2.7/site-packages/ipdb/__init__.py", line 16, in <module>
    from ipdb.__main__ import set_trace, post_mortem, pm, run, runcall, runeval, launch_ipdb_on_exception
  File "venv/lib/python2.7/site-packages/ipdb/__main__.py", line 51, in <module>
    ipshell = InteractiveShellEmbed()
  File "venv/lib/python2.7/site-packages/IPython/terminal/embed.py", line 92, in __init__
    display_banner=display_banner
  File "venv/lib/python2.7/site-packages/IPython/terminal/interactiveshell.py", line 328, in __init__
    **kwargs
  File "venv/lib/python2.7/site-packages/IPython/core/interactiveshell.py", line 483, in __init__
    self.init_readline()
  File "venv/lib/python2.7/site-packages/IPython/core/interactiveshell.py", line 1888, in init_readline
    self.refill_readline_hist()
  File "venv/lib/python2.7/site-packages/IPython/core/interactiveshell.py", line 1897, in refill_readline_hist
    stdin_encoding = sys.stdin.encoding or "utf-8"
AttributeError: DontReadFromInput instance has no attribute 'encoding'

Clean up return statements

The tags currently return None implicitly for no-op behavior (when TEMPLATE_DEBUG is not set to True). This can cause "None" to appear in the browser. Returning a blank string seems more reasonable

Add sphinx docs

Mark as Python 3 compatible

According to issue #11 django-template-debug should be compatible with Python 3, but https://caniusepython3.com/project/django-template-debug does not know about it.

It uses the caniusepython3 tool, which looks at the categories from setup.py:

% caniusepython3 --verbose --projects django-template-debug
[INFO] 1 top-level projects to check
Finding and checking dependencies ...
[INFO] Fetching project list for 'Programming Language :: Python :: 3'
[INFO] Fetching project list for 'Programming Language :: Python :: 3.0'
[INFO] Fetching project list for 'Programming Language :: Python :: 3.1'
[INFO] Fetching project list for 'Programming Language :: Python :: 3.2'
[INFO] Fetching project list for 'Programming Language :: Python :: 3.3'
[INFO] Fetching project list for 'Programming Language :: Python :: 3.4'
…
[INFO] Locating django-template-debug

You need 1 project to transition to Python 3.
Of that 1 project, 1 has no direct dependencies blocking its transition:

  django-template-debug

So at least Programming Language :: Python :: 3 should get added, but probably all versions which are supported.

Enable for Python 3 usage

Add developer docs

• Needs a requirements file for test requirements (tox and sphinx)
• Needs some instructions on local setup for developers, especially with regard to the settings file to point to for tests

The no-op behavior for each tag is contingent on the same conditional. This should be refactored into a decorator

Specifically, I mean the check for "if TEMPLATE_DEBUG" in every function

Add tox configuration for testing against multiple environments

Question about output

I've been using django-template-debug with the Wagtail CMS, and I'm getting unexpected output from this projects tags. For example:

{% variables %}
{% attributes self %}
{% details self %}

Produces:

['False', 'None', 'True', 'hero_photo', 'self', 'value']

<filter object at 0x111da2e48>

{'get': 'routine', 'update': 'routine', 'pop': 'routine', 'copy': 'routine', 'keys': 'routine', 'popitem': 'routine', 'block': <home.models.RichTextWithForm object at 0x110d729e8>, 'setdefault': 'routine', 'fromkeys': 'routine', 'move_to_end': 'routine', 'bound_blocks': OrderedDict([('body', <wagtail.wagtailcore.blocks.base.BoundBlock object at 0x111da2940>), ('image', <wagtail.wagtailcore.blocks.base.BoundBlock object at 0x111da2ac8>), ('reverse_text', <wagtail.wagtailcore.blocks.base.BoundBlock object at 0x111da22b0>), ('resource_given', <wagtail.wagtailcore.blocks.base.BoundBlock object at 0x111da2e10>), ('save_contact_to', <wagtail.wagtailcore.blocks.base.BoundBlock object at 0x111da2320>)]), 'clear': 'routine', 'items': 'routine', 'values': 'routine'}

I routinely get results like this, so I never use the attributes tag, and I have to dig around all the routine values to find meaningful values.

I'm wondering if this has to do with the Wagtail CMS, or if it has to do with Django changing over the last two years.

Show the file and line number of each method

Tests

This project could use some simple tests, especially tests that verify that exceptions are caught and handled properly.

Link in readme to "Example Usage" is 404

:(

Switch back to using TEMPLATE_DEBUG setting for determining no-op behavior

Feedback indicated that this setting makes more sense and I concur

Test with newer versions of Django

The tox.ini was last updated before the release of Django 1.5

Ideally, we should support Django >=1.3, at least through 1.6. I don't expect there to be any significant changes needed in order for new versions to work with the tool, they just aren't tested yet.

Add introspection tags using tracerlib

These might help with the following use cases, though others might be found:

1. Locating the function name and file name of the view that is rendering the current template
2. Locating the file name, line number and other information about callables available to the context

Django 1.8 Depreciation Warnings

WARNINGS:
?: (1_8.W001) The standalone TEMPLATE_* settings were deprecated in Django 1.8 and the TEMPLATES dictionary takes precedence. You must put the values of the following settings into your default TEMPLATES dict: TEMPLATE_DEBUG.

Fixing it shouldn't be too hard. Just need to either rename the variable, or work out the correct way to move the setting into the TEMPLATE dict.

get_details() errors on booleans

I've only seen this in a Python3 project. My suspicion is that the promotion of True/False to keywords changes the attributes they can be expected to have. Changing how these are handed in utils.py:get_details() should be sufficient to fix this. The fix should be fairly easy to test once tox is configured to run python3.X environments.

I can't recall if the error was an AttributeError exactly, but it should be easily reproducible.

Make details() more restrictive, to only show attributes available in the template

The following attributes should be left out of the list

• Callables with alters_data
• Private attributes (anything starting with _ or __)
• callables that require arguments