Breaking out Django templates into a standalone library - Django developers

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Breaking out Django templates into a standalone library
Received-SPF: pass (google.com: domain of ubernost...@gmail.com designates 209.85.198.190 as permitted sender)
DomainKey-Status: good (test mode)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=gOYyFiL6f6Lvgolup41+IKjQY/W6ibJtWz0GN4R/2UjWqoQC1FtQ88/Sv6a71AZW/RZ4sC22t64vISAsmxugUlp0tUhyb0D7xVsTN0Ug8dy9XBlOZp4RBhr+Rt5r33TgsAkQlSk+dgINuLbBXuyBwZf5v0nbccL+9++POO2+k48=
Message-ID: <21787a9f0708072303n38b73638s585c1d3ba66a5e56@mail.gmail.com>
Date: Wed, 8 Aug 2007 01:03:11 -0500
From: "James Bennett" <ubernost...@gmail.com>
To: django-developers@googlegroups.com
Subject: Re: Breaking out Django templates into a standalone library
In-Reply-To: <bf0b20a90708072227s6c4fd478t20859e4218154e40@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <bf0b20a90708071539o1aa334b4x1aebc3e3b4550...@mail.gmail.com>
	 <6464bab0708071607u382b08f7gbb4fc8dac8c2...@mail.gmail.com>
	 <bf0b20a90708072227s6c4fd478t20859e4218154...@mail.gmail.com>

On 8/8/07, Tom Tobin <korp...@korpios.com> 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."
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
