Modularised Django

[Armin Ronacher <armin.ronacher@…>]

Django is the most ass kicking webframework ever created. So why not share knowledge and modules? There is a ​discussion on django-developers about split out the template engine and the ORM System.

I personally like the idea but how should this work?

1. these module must not read DJANGO_SETTINGS_MODULE and other dependencies
2. they shouldn't require a download of the whole django framework
3. when used in django there shouldn't be too many (none) changes which might break backwards compatibility

The problem will be the last point in combination with the first two :-)

[Fredrik Lundh <fredrik@…>]

I can whip up a patch based on my proposal, in case anyone's interested (in brief: lazy access to the settings object/module, users may call django.template.setup before doing anything else if they don't want django's default setup).

[Jacob]

That sounds like a very good idea, Fredrik; a patch would be quite welcome.

[hugo]

oh, please do that in the magic-removal branch, as that already has the refactored settings stuff.

[Luke Plant]

I paste binned this for Adrian's review during the sprint, but in case it gets lost I'm adding it here. It's a patch that gets the template part of Django modularised, and provides a bit of a basis for doing the rest. My notes are below, the patch is attached

The basic implementation is as below:
In django/template/__init__.py replace

  from django.conf import settings

with:

  settings = LazySettings()

In django/template/*.py replace:

   from django.conf import settings

with:

  from django.template import settings

Then there are a few bits and pieces that have to be changed to keep 'settings' from looking itself up in django.conf too early.

Some issues:

1. Tests - I've added some, but because of DJANGO_SETTINGS_MODULE the test modules can't be imported into the existing test suite. Instead I've created a 'standalone' dir that contains test scripts that should just be run using system(), and a script 'standalone_tests.py' that executes all the scripts in that dir.

2. Default template settings: at the moment I've just duplicated the relevant parts of global_settings in django/template/__init__.py. This obviously isn't OAOO, but I'm not sure how else to do it without ending up in all kinds of import loops or defeating the aim.

3. The 'configure' method for template: maybe this should just have a list of explicit keyword arguments instead of having the TemplateSettings class.

4. LazySettings - this bit is actually reusable for modularising other parts of the system. It might not want to live in datastructures though.

[Luke Plant]

Patch to begin implementation of this ticket

[Malcolm Tredinnick <malcolm@…>]

An updated version of Luke's patch that tries to work for all cases.

[Malcolm Tredinnick <malcolm@…>]

This latest patch uses Luke's ideas and tries to make them work for all Django subsystems. There is nothing specific about the templating system in there now. Documentation patches included, so usage should hopefully be clear. Can't test it yet as part of the automated test suite (still working on that), but running tests/othertests/templates.py on its own will test these changes (it is forced to run in standalone mode).

[Adrian Holovaty]

I'm looking at this patch...

Why is LazySettings.__setattr__() using this:

self.__dict__['_target'] = value

...instead of this?

self._target = value

[Luke Plant]

adrian: I think that originally came from me tying myself in knots trying not to trigger __getattr__ from __setattr__ in the case where you are trying to set the '_target' attribute. I think the method should look like this:

    def __setattr__(self, name, value): 
        if name == '_target':    
            setattr(self, '_target', value)
        else: 
            setattr(self._target, name, value) 

[Adrian Holovaty]

(In [2927]) Fixed #1321 -- Made DJANGO_SETTINGS_MODULE optional. You can now call django.conf.settings.configure() to set settings manually if you don't have a settings module. Thanks, Malcolm Tredinnick, Luke Plant, Fredrik Lundh

[Adrian Holovaty]

Luke -- Ah, that explains it. I added a comment in the code in [2929].

[(none)]

Milestone Version 1.0 deleted