在 Google App Engine 中调试 Jinja2
当我在 Google App Engine 中运行 Jinja2 时,我得到无用的调试信息。我认为这是因为常见问题解答中的此项目:
我的回溯看起来很奇怪。发生了什么事?
如果加速模块未编译,并且您使用的是不带 ctypes 的 Python 安装(不带 ctypes 的 Python 2.4、Jython 或 Google 的 AppEngine),Jinja2 无法提供正确的调试信息,并且回溯可能不完整。目前 Jython 或 AppEngine 没有好的解决方法,因为 ctypes 在那里不可用,并且无法使用加速扩展。
虽然目前没有“好的”解决方法,但是否有任何解决方法可以使出现异常时打印的信息更有帮助?
感谢您的阅读。
布莱恩
When I'm running Jinja2 in Google App Engine, I get useless debugging information. I gather this is because of this item in the FAQ:
My tracebacks look weird. What’s happening?
If the speedups module is not compiled and you are using a Python installation without ctypes (Python 2.4 without ctypes, Jython or Google’s AppEngine) Jinja2 is unable to provide correct debugging information and the traceback may be incomplete. There is currently no good workaround for Jython or the AppEngine as ctypes is unavailable there and it’s not possible to use the speedups extension.
While there is no 'good' workaround for this at the moment, is there any workaround so that the information printed when exceptions arise can be made more helpful?
Thank you for reading.
Brian
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
避免猴子修补(取决于 SDK 内部结构变化)的一种方法是使用
imp
模块,至少目前在本地开发环境中尚未禁用该模块。然后只需像这样加载_ctypes
即可更好地进行 Jinja2 调试:A way to avoid monkey-patching (which depends on the changing internals of the SDK) is to use the
imp
module, which is at least currently not disabled in the local development environment. Then just load_ctypes
like this to enable better Jinja2 debugging:当我遇到这样的问题时,我尝试在本地 iPython shell 上调试它。我想知道产生这样的错误的代码是什么。应该有一种方法来为其编写测试。
When I hit a problem like that I try to debug it on my local iPython shell. I wonder what the code that generates such a bug is. There should be a way to write a test for it.
您可以通过使用 Monkeypatching 将 _ctypes 和 gestalt 添加到开发服务器的 C 模块白名单来解决此问题。
为此,请将以下代码片段放在 main.py 的顶部:
如果您有类似的仅限本地模块的需求,您还可以使用此技巧来启用其他 C 模块。请注意,一旦部署,这些模块实际上仍然无法工作,因此请小心行事。
在使用 python2.7 的 SDK 1.6.3 上,您需要将上述代码更改为:
在适用于 python 2.7 的 SDK 1.8.6 上,尝试以下操作:
You can get around this by adding _ctypes and gestalt to the development server's C module whitelist with monkeypatching.
To do so, put the following snippet at the top of your main.py:
You can also use this trick to enable other C modules, if you have similar local-only module needs. Do note that these modules still won't actually work once you deploy, so tread carefully.
On SDK 1.6.3 using python2.7 you need to change the above code to:
On SDK 1.8.6 for python 2.7, try this:
也许只需使用 PyCharm 的交互式调试器并逐步执行代码:
http://www.jetbrains.com /pycharm/quickstart/#RunAndDebug
Perhaps just use PyCharm's interactive debugger and step through the code:
http://www.jetbrains.com/pycharm/quickstart/#RunAndDebug
当 Jinja2 模板渲染期间发生异常时,我使用以下 Monkeypatch 来启用稍微更有用的信息:
这将导致错误日志中的异常回溯稍微更准确。我认为它通常不会准确地向您显示出了什么问题(但如果我没记错的话,有时会这样做),但它至少会将异常范围缩小到正确的模板。
我不知道(或不记得)为什么会这样。
例如,我刚刚添加了一些代码,这些代码将触发我的模板之一的异常。在开发服务器下,这是“正常”异常处理程序向我显示的内容:
但异常不在
accounts/base.html
模板中,而是在accounts/edit_card.html
中代码>.这是在 App Engine 上调试 Jinja2 模板异常时最令人沮丧的部分:异常的来源几乎总是被歪曲。根据我的经验,源通常被报告为父模板或某些模板宏。安装异常日志monkeypatch后,相同的异常会在日志中生成此回溯:
这里仍然有很多无关的信息,但此回溯至少为我指明了正确的方向。它声称问题出在
accounts/edit_card.html
的第 54 行(正确的模板),但实际的异常发生在第 86 行。但是考虑到正确的模板和正确的异常,我可以相当很容易发现麻烦的代码是
模板上下文中没有
sequence
变量的地方。这不是一个完美的解决方案,但我发现它非常有帮助。
I use the following monkeypatch to enable slightly more helpful information when an exception occurs during Jinja2 template rendering:
This will result in slightly more accurate exception tracebacks in your error logs. I don't think it usually shows you exactly what went wrong (but if I remember correctly it sometimes does), but it will at least narrow the exception down to the correct template.
Why this works, I do not know (or cannot remember).
As an example, I just added some code that will trigger an exception to one of my templates. Under the development server, this is what the "normal" exception handler shows me:
But the exception is not in the
accounts/base.html
template, it's inaccounts/edit_card.html
. This is the most frustrating part of debugging Jinja2 template exceptions on App Engine: The source of the exception is almost always misrepresented. In my experience, the source is usually reported as either the parent template or as some template macro.With the exception logging monkeypatch installed, the same exception generates this traceback in the logs:
There's still a lot of extraneous information here, but this traceback at least points me in the right direction. It claims that the problem is on line 54 of
accounts/edit_card.html
(the correct template), but the actual exception occurs at line 86.But given the correct template and the correct exception, I can pretty easily find that the troublesome code is this
where there is no
sequence
variable in the template context.This isn't a perfect solution, but I've found it mighty helpful.
不确定这是否有帮助,但至少可以添加像 django 的“调试”这样的块模板标签,这至少有助于定位问题。
Not sure if that will be helpful, but it might be possible to at least add block templatetag like django's 'debug' which will at least help to localize the problem.