On Tue, 2007-08-07 at 17:39 -0500, Tom Tobin wrote: > At the end of the angsty autoescaping thread (said angst in no small > part from my direction ^_^), I floated the idea that perhaps my > concern over autoescaping was pointed in the wrong direction -- that it > might be time to split Django's template module out into a standalone > library. The idea has been raised before, but discussion always hits > the point of "good idea, but a PITA ..." and a combination of time > constraints and the bystander effect kick in to shelve it.
That isn't my recollection, and I was involved in some of those previous discussions. The main argument is that it isn't a really good idea, for reasons outlined below. You don't address why we would want to do this. What's the really compelling use-case that isn't already handled by installing Django and just using the templating code with standalone configure (via settings.configure())? Package size isn't the argument -- Django is relatively small and you don't gain that much by isolating the templates, once you include all the supporting stuff, since the bulk of the disk usage of Django is in the PO files. > Since I've been championing the use of Django's template library as a > general purpose library, and spending plenty of time in the guts of > the template code while writing the taghelpers module, I may as well > step up and offer to do this. And no, I don't want another Jinja [1] > [2]; I want a Django template library that's still distributed as part > of Django, in the Django namespace, and available in its separate > split-off form from the Django website, similar to how the various > Twisted modules are distributed [3]. > > I know there are various obstacles here, the largest one being the use > of Django settings in the template code -- but nothing looks > unsurmountable. The main reason we implemented standalone configuration (via settings.configure()) was so that you could use the template library in isolation. At the time (starting about 18 months ago), we had a bit of a debate about where to include the defaults (in django.conf or django.templates, etc) and decided the current approach wasn't really hindering anything and meant there was only one spot you had to look for things. > I'd ideally like to have this done in time for Django 1.0, and to > ensure stable releases in line with future Django releases. > > So ... thoughts? Please, no. The main problems are (1) It's not really worth it, since installing all of Django and then just not using part of it is easy -- it's not a huge package after all. Experience has shown that the Twisted split hasn't been a no-brainer success. By and large, the easiest thing to do, even with Twisted, is install everything and just use the bits you need. Otherwise you spend ages wallowing around trying to work out which bits you do need. When it comes to packaging for distros, Twisted either has to be done as one mega-package or something like TurboGears or Pylons as a combination of a bunch of individual packages (usually the latter). That latter situation is a packaging strategy Django intentionally avoids and it will make downstream packaging after 1.0 much easier. People just have to install django-1.0. (2) It leads to problems with debugging, installing, setting up and helping people when they have both the separate library and the whole Django package installed. Which template portion is being used, etc? Are they up-to-date? Are they interfering with each other? If everything's in one package, then we only have to worry about the people who have multiple Django versions installed and that's much easier to debug. (3) If the goal is that django-core will use django-templates, we are going down the Pylons path. Batteries included is a good philosophy for something the size of Django, though. If the goal is that django-core will duplicate django-templates, you have problems (1) and (2), above. Regards. Malcolm -- Save the whales. Collect the whole set. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
