Hi everybody,
Everyone loves the way templates are discovered in django.
No one loves settings.py that much.
This is proposal on how to improve situation significantly.
Configuration facility is suggested in addition to django.conf.settings.
Configuration is going to be put into conf/ directory of the project
(or settings/ -- just set config.global.CONFIG).
:: settings.py ::
from django.conf import config
from os.path import dirname, abspath, join
ROOT = dirname(abspath(__name__)) # type 'str'
INSTALLED_APPS = ...
config.global.ROOT = ROOT
config.global.CONFIG = join(ROOT, 'conf')
config.autodiscover()
# config.global is in fact a synonym for settings
:: conf/global.py ::
# runs before the app settings
from django.conf import config
from os.path import dirname, abspath
ROOT = config.global.ROOT # type 'str', empty if not set.
config.global.JQUERY.default = JQUERY = ROOT +
'static/js/jquery-1.3.2-min.js' # type 'dict', setting default value
for missing items
config.global.JQUERY['1.3.2'] = JQUERY # type 'unordered dict with
default value', now setting arbitrary key
config.global.MEDIA += [ROOT + 'static/js/'] # type 'ordered set with
default value'
config.global.DATABASES['default'] = {...} # backward-compatibility,
so using 'default' not .default!
# Note: after type is set for constant, the type can't be changed.
# Note: please set to tuple not list if you need a clear sign the
option won't be additive any more.
:: conf/global_overrides.py ::
# runs after all other settings but before <site>_overrides, see below
# is now empty
:: conf/apps/myapp.py ::
# runs after all app-specific settings
app.DATABASES['db3'] = {...}
app.ROUTERS += ['Db3_is_readonly']
:: conf/www_server_com.py
# runs before app-specific settings
from django.conf import config
config.global.MEDIA_ROOT = '/var/site/www.server.com/site_media/'
config.global.MEDIA_URL = 'media.server.com'
app.MIDDLEWARE += ['caching.smart_caching_app.SmartCacher']
:: conf/www_server_com_overrides.py
# runs after app-specific settings
config.global.JQUERY['1.3.2'] = 'static/packed.js'
config.global.JQUERY['1.4.2'] = 'static/packed.js'
:: myapp/conf.py ::
# runs in order specified in INSTALLED_APPS
from django.conf import config
app = config.apps.myapp
app.DEPENDS += ['django.contrib.auth']
app.STATIC = app.global.ROOT + 'media/myapp/'
app.IMAGES = app.global.ROOT + 'media/uploads/images/'
app.THUMBS = app.global.ROOT + 'media/uploads/thumbs/'
config.global.MEDIA += [app.IMAGES, app.THUMBS, app.JSES, app.CSSES]
config.global.JQUERY['1.4.2'] = STATIC + 'js/'
config.global.TAGS += ['app1.templatetags.mytags']
:: myapp/forms.py ::
from django.conf import config
app = config.apps['myapp']
class MyForm:
class Media:
css = app.STATIC + 'css/base.css'
js = config.global.JQUERY['1.4.2']
The ultimate order:
django/conf/global.py
conf/__init__.py
conf/global.py # -- you can also set your own personal order there
conf/<site*>.py
app1/conf.py # -- single pass is enough, cause applications can both
provide callbacks for later configuration stages.
app2/conf.py
...
appN/conf.py
conf/apps/app1.py
conf/apps/app2.py
conf/apps/appN.py
conf/global_overrides.py
conf/<site*>_overrides.py
*<site> for www.my-site.com is www_my__site_com (dots replaced with
underlines, dash with double underline).
socket.getfqdn() is used for determining current site.
The motivation is simple:
the bigger your list of application grows, the larger configuration
you will have!
Django has more than 100 of different settings options.
They are not even grouped now.
I hope such django "built-in" type of configuration will suit 99% of
the possible Django projects, and will make django community much
stronger.
I'm going to create a prototype.
Expected benefits:
- 3rd-party applications can be used without a bit of touching and
still customized perfectly.
- Application can connect to each other in dynamic way, or provide
different kinds of plugin points.
- Fixed models dependencies can be replaced with dynamic (i.e, each
application might ask for personal User or UserProfile replacement)
- Really simple media setup for both development and production servers.
- A number of development and production configurations can coexist
in the project, without single 'if'
- Per-application configuration for middlewares, databases, routers,
context processors and other "additive" options
- Preconditions for visual application settings (Needs another proposal)
- Django core settings will be moved to namespaces and grouped semantically.
- Sparse config is better than dense.
Why it needs to be in the django core, not just 3rd-party plugin:
- Because "Namespaces are one honking great idea -- let's do more of those!"
- Because config ubiquity between projects is the main project benefit.
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
