Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for a {% debug %} extension tag. #798

Closed
wants to merge 0 commits into from

Conversation

@ShaheedHaque
Copy link
Contributor

ShaheedHaque commented Jan 14, 2018

This dumps the available variables, filters and tests. See Issue #174.
This is roughly equivalent to the Django Template Language {% debug %} tag, and typical usage like this:

{% debug %}

produces output like this:

        {'context': {'_': <function _gettext_alias at 0x7f9ceabde488>,
                 'csrf_token': <SimpleLazyObject: 'lfPE7al...q3bykS4txKfb3'>,
                 'cycler': <class 'jinja2.utils.Cycler'>,
                 ...
                 'view': <polls.views_auth.Login object at 0x7f9cea2cbe48>},
        'filters': ['abs', 'add', 'addslashes', 'attr', 'batch', 'bootstrap',
                 'bootstrap_classes', 'bootstrap_horizontal',
                 'bootstrap_inline', ... 'yesno'],
        'tests': ['callable', 'checkbox_field', 'defined', 'divisibleby',
               'escaped', 'even', 'iterable', 'lower', 'mapping',
               'multiple_checkbox_field', ... 'string', 'undefined', 'upper']}

The output under Python2 and Python3 below 3.4 is slightly less compact, as pprint.format() did not introduce the 'compact' argument before 3.4.

@davidism

This comment has been minimized.

Copy link
Member

davidism commented Jan 15, 2018

It would be interesting to support syntax like {% debug html-table %} to produce a table when you know you're in an HTML template.

@ShaheedHaque

This comment has been minimized.

Copy link
Contributor Author

ShaheedHaque commented Jan 15, 2018

To be honest, that seems like overkill given that this is a debug facility intended to efficiently serve the all-too-common scenario of "Hmmm, I'm not quite sure what all the context variables are" using built-in Python string formatting. If table support was needed, perhaps it would be better to introduce some kind of a magic {{ debug }} which returned the equivalent dict, and allowed the user to select what was needed and how it should be styled?

@davidism

This comment has been minimized.

Copy link
Member

davidism commented Jan 15, 2018

That's the other thing I was thinking. Using a tag means you can't access the data directly, unless you were to turn it into a block tag like call.

@ShaheedHaque

This comment has been minimized.

Copy link
Contributor Author

ShaheedHaque commented Jan 15, 2018

True, but that sounds like a whole different thing: its not a tag for the reason you suggest, nor is the idea of a "magic" context variable that contains all other context variables/filters/tests a "nice" thing. That all but calls for new syntax {{ %reserved-thing% }}, for example. I believe the requirement being addressed here is much simpler than full scale access to that data.

@ShaheedHaque

This comment has been minimized.

Copy link
Contributor Author

ShaheedHaque commented Jan 18, 2018

If you'd prefer not to accept this PR, please do let me know (the downstream project I'd originally submitted this to might be an alternative home).

jinja2/ext.py Outdated Show resolved Hide resolved
@davidism

This comment has been minimized.

Copy link
Member

davidism commented Jan 18, 2018

I'd like to hear from @mitsuhiko or @ThiefMaster before merging.

In order to use it, you need to know about and enable the extension first, add a tag, and you only get a squashed, non-interactive representation that isn't JSON compatible.

There are already things like Flask-DebugToolbar. The user can also set a breakpoint in a debugger and look at the context directly:

pycharm-jinja-debug

jinja2/ext.py Outdated Show resolved Hide resolved
jinja2/ext.py Outdated Show resolved Hide resolved
jinja2/ext.py Outdated Show resolved Hide resolved
jinja2/ext.py Outdated Show resolved Hide resolved
tests/test_ext.py Outdated Show resolved Hide resolved
@ShaheedHaque

This comment has been minimized.

Copy link
Contributor Author

ShaheedHaque commented Jan 18, 2018

Of course, it is completely reasonable that you and the community must feel comfortable with what is proposed. If its not the right thing for Jinja, so be it. In the meantime, thanks for the excellent feedback, I will address the points noted.

On the general comments...

  • about this being an extension. Yes, I packaged it that way because I thought that seemed like a plausible approach. I'm fine if you prefer to make it part of the default tag set.
  • about the output not being JSON, I should just point out that the data exposed is commonly not vanilla data, at least in the Django context. There are ellipses present, but that's only because I specifically limited the output depth. If you prefer, I could remove that limit. Barring that, it looks like JSON to me...though I've not reviewed how pprint works..is there some case you have in mind?
  • about the output not being interactive. I'm not sure quite what you had in mind, but interaction was not something I think belongs in this context.
  • about alternate debug facilities. I use PyCharm too, but it turns out that at least for Django-users, breakpoints are not supported with Jinja...only DTL is supported. There are also plenty of scenarios where I think a simple dump is useful.

Edit It turns out that the docs are wrong, as you say provided the file type association is set correctly, Django with Jinja can be debugged just fine under PyCharm. I'll look to file an upstream doc bug.

@davidism

This comment has been minimized.

Copy link
Member

davidism commented Jan 18, 2018

JSON uses double quotes around strings. Values that aren't JSON types should be converted to string (this is not trivial).

Interactive as in I can access it as a varaible and render it how I want.

PyCharm says it supports debugging Jinja templates, so if that isn't the case it needs to be reported to PyCharm. Are you sure you selected "Jinja2" for the template language in the project? Are you sure that the file is detected as a Jinja template (it can be changed in the file association settings)?

@ShaheedHaque

This comment has been minimized.

Copy link
Contributor Author

ShaheedHaque commented Jan 18, 2018

I think I've addressed the comments, but it is not clear to me how to verify the markup-related suggestions (I had to work around an unrelated doc build failure locally, but the Travis build fails in some way that seems likely related to my change...I'll have to experiment to fix it).

  • On the JSON format. I'm happy to look at that if that becomes the blocking issue.
  • On the interactive thing. I have no idea how to implement that and it is not of interest to me.
  • On the PyCharm support. The link I provided is to the official PyCharm docs: the combination of Django and Jinja is not expected to work.
jinja2/ext.py Outdated Show resolved Hide resolved
@ShaheedHaque

This comment has been minimized.

Copy link
Contributor Author

ShaheedHaque commented Jan 18, 2018

I've no idea why the doc build is failing under Travis:

Warning, treated as error:
/home/travis/build/pallets/jinja/docs/templates.rst:1314:Could not lex literal_block as "jinja". Highlighting skipped.
ERROR: InvocationError: '/home/travis/build/pallets/jinja/.tox/docs-html/bin/sphinx-build -W -b html -d /home/travis/build/pallets/jinja/.tox/docs-html/tmp/doctrees docs docs/_build/html'

I do get a different error locally, but if I make this change on about line 307 of docs/extensions.rst:

- :members: push, look, eos, skip, __next__, next_if, skip_if, expect
+ :members: push, look, eos, skip, next_if, skip_if, expect

then I get a clean local build. I don't see how this can be related to my changes, so I fear I'm a bit stuck.

@ShaheedHaque

This comment has been minimized.

Copy link
Contributor Author

ShaheedHaque commented Feb 4, 2018

I note that PR #802 has the same doc build failure.

@pallets pallets deleted a comment from dwt Dec 3, 2018
@kevin-brown kevin-brown closed this May 6, 2019
@kevin-brown kevin-brown force-pushed the ShaheedHaque:master branch from d55ab2a to fd89fed May 6, 2019
@davidism davidism added this to the 2.11.0 milestone Oct 5, 2019
@davidism

This comment has been minimized.

Copy link
Member

davidism commented Oct 5, 2019

Continued and merged in #983.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.