On 8/7/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > 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.
Err, to make it more straightforward for others to use *just* the templating system? > 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. You're right, package size *isn't* the argument; when it comes down to it, many people don't like installing stuff they have zero intention of using. > > 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. That doesn't mean we can't re-approach the idea, assuming it was done well. > > 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. People will *still* be able to just install django-1.0. Perhaps I didn't explain the packaging situation quite as clearly as I could have; the Django templating system would *still* be distributed as part of Django, in the django.template namespace. No separate package required. Batteries included. The Twisted analogy was meant to draw a parallel more with the namespacing than enforced separation (and even for Twisted, there's always the "Sumo" package). > (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. See point above. > (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. Partially see point above; I intend that the Django template system continue to be distributed alongside Django, and for the Django packaging system to pull in the Django template library. No duplication is involved; there would be only one place for django-template code development. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
