On 8/8/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > I'd ideally like the Django installer to detect if django.template was > already on the system, and drop Django into the same spot. As far as > versioning, Django should check for a minimum version of Django > templates (i.e., the version at the time of that Django's release), > assuming it was already installed on the system; if it detected a > version below the minimum, it would be nice for the installer to offer > to simply overwrite the entire django namespace.
In theory, setuptools can do this sort of "namespace" trick, but the system which handles that has always seemed a little clunky to me. If you manage this feat with the template system, how would you feel about trying the same trick with other components? If there *is* a clean solution (and I'm not sure there is), it'd be nice to offer, say, the ORM as a standalone component (if nothing else it'd provide a permanent answer to the "how do I use the ORM without writing a web app" question). Though I think Malcolm's right in that we've already done what's technically *necessary* to allow the template system to be used standalone, I'd be interested to see if we can make it more convenient to do so (though if we'd done that from the start, Jinja might never have happened, and I know some folks who are fond of it). All the stuff we do at World Online with non-web-app uses of the template system take place on boxes that already have a full Django stack installed, so it wouldn't really affect us either way, but it couldn't hurt to see if we can make it easier for folks who want to just use templating. My biggest worries, though, aren't actually the settings, because it'd be easy enough to provide some hook for manually specifying a loader and directories (context processors aren't too difficult because RequestContext already accepts a keyword argument for those): 1. The search path for tag libraries is still the magic "django.templatetags" module; either that'd have to change, or the package would have to provide both django.template and django.templatetags. 2. All the useful bits for unit-testing templates live in django.test, and all the actual tests for the template system itself live in tests/regressiontests/templates outside even the "django" namespace. Solving that one may be trickier than it looks ;) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
