This is a bit long for a ticket writeup, but I wanted to get some
comments on it, so here goes:
The "magic" that still goes on in the templatetag system has been
discussed before on the list[1], and the consensus was that, since
it's relatively invisible and harmless, it's OK for it to stay.
Except it's not completely invisible and harmless. Consider a
templatetag library, living in 'myproject/myapp/templatetags/', which
looks like this:
from django.template import Library
import foo
register = Library()
def add_foo():
return foo.bar()
register.simple_tag(add_foo)
If the application which includes this library is installed on a
machine which doesn't have the 'foo' module, we would expect to get an
ImportError saying "No module named foo".
But instead, if we try to do '{% load myapp %}' in a template, we'll
get a TemplateSyntaxError and the message that 'myapp' is not a valid
tag library. Even worse, the ImportError will have completely
disappeared; the exception will appear to have originated as
InvalidTemplateLibrary.
The reason for this is that django/templatetags/__init__.py, when it
loops over INSTALLED_APPS to find templatetag libraries,
indiscriminately quashes ImportError -- apparently on the assumption
that any ImportError being raised is a result of a non-existent
'templatetags' module.
This is both frustrating and counterintuitive.
There are two ways I can think of to solve this problem:
1) Document the way templatetag loading works, and advise tag authors
to wrap any imports they need in try/except and handle the situation
as appropriate (for example, by returning nothing from their tag, or
possibly raising ImproperlyConfigured with a message that a given
third-party module needs to be installed). This is a bit of a wart,
but at least it would get the issue documented so that people don't
have to go digging in the source to figure out what causes it.
2) Tweak django/templatetags/__init__.py to introspect the ImportError
it gets and figure out whether the exception came from a non-existent
'templatetags' module (in which case it can be safely quashed) or from
something in a tag library failing to import a needed module (in which
case the exception should keep propagating in some form so it will
appear in the eventual traceback). Given that we know what the
exception would look like for a non-existent templatetag library ("No
module named myapp.templatetags"), this probably wouldn't be terribly
hard to accomplish.
Obviously I prefer the latter, since it results in more intuitive
behavior, but I'm interested in hearing what other people think about
this.
[1]
http://groups.google.com/group/django-developers/browse_thread/thread/f9aec919b1449539/cb7a69b7e4b6447e
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
