On Sat, Jun 5, 2010 at 5:07 PM, Tom Evans <tevans...@googlemail.com> wrote: Hi Tom, > I'm not going to reply again, Russell has quite clearly ruled this out > but to reply to these points: > > As the project manager, you can already use automatic configuration - > its python, you can do whatever the heck you like. Your scope is not > limited in any way, and if you want to auto-discover default settings > from your installed apps, do so. You could even formalize this into a > django app, publish it on googlecode and see how widely it is used by > people without requiring any changes to django itself. If such a > feature where to become standardized, and popular, then it could > potentially then be included into django.contrib, but it's completely > orthogonal to django itself - this is the benefit of using python for > configuration. I did: http://github.com/buriy/django-configurator > In our deployments, a project has a default configuration, which is > then overridden by a site specific settings_local.py, which is checked > out on a site by site basis alongside settings.py. > > This is then imported into our settings with code like so: > > try: > from settings_local import * > except: > # It's ok to not have any local settings. > pass > > # Convert INSTALLED_APPS and MIDDLEWARE_CLASSES into lists, > # so we can append any extra ones supplied in settings_local.py > if EXTRA_APPS: > INSTALLED_APPS = list(INSTALLED_APPS) + EXTRA_APPS > if EXTRA_MIDDLEWARE: > MIDDLEWARE_CLASSES = list(MIDDLEWARE_CLASSES) + EXTRA_MIDDLEWARE These are exactly my hate patterns. The goal of django-configurator was to get rid of them in the projects I have.
Btw, you are not yet using the "state of the art" python-based solution: storing different local_settings in the version control system, so do a dynamic import based on computer DNS name. > It is hardly a stretch to see how this kind of code could be extended > to try to import settings_auto or settings_default from each app in > installed apps. Sorry, I'm not native speaker. Can't understand what's "hardly a stretch" neither from context nor from dictionary. >>> For example - you say that your application needs to run in a separate >>> database. My DB Admin (or hosting provider) won't let me have another >>> database instance. How does your automated "add this extra database" >>> approach handle the case where I don't want you to add another >>> database? >> Well, in some alternative reality, an app creator might really want to >> define a router and a special database because it's cool, not because >> it really needs to use its legacy database with its legacy table >> names. >> >> If you're afraid of using configurations incorrectly, you might either: >> - turn off auto configuration as a whole >> - redefine the DISCOVERY_ORDER as you want. >> options.lazy.INSTALLED_APPS is a function. >> - override the application option in conf/apps/app.py or >> conf/global_overrides.py . > > It's not fear, its confidence. As the project manager, you should be > in control of what configurations are set, not application developers. > How do you propose that an application insert middleware? How do you > solve the ordering issues for settings like that? These problems > aren't insurmountable, but it is just easier to be in control of these > settings yourself. How hard is it to read a README and configure the > right settings for your project. I am of control. That's why god gave us ability to override. It seems you are not aware what I suggest. -- 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.
