On Mon, Jun 7, 2010 at 4:39 PM, Tom Evans <tevans...@googlemail.com> wrote: > Are you proposing to determine the host name and then dynamically > import settings from that named configuration file? What a kludge - > that would require having every configuration file for all your sites > checked out in the same place. I'm not requiring anything. You can set your own DISCOVERY_ORDER for your settings files. You can not use autodiscovery at all.
I'm talking not about requirements but abilities. > Each of my deployments has its location specific configuration > deployed from administration RCS repo by cfengine to > settings_local.py, you can keep your 'state of the art'. How about development? Everyone's copy-pasting required settings from settings_local.py.template ? > >>> 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. > > How about this - 'It is easy to see how this kind of code could be > extended to try to import settings_auto or ....' I still don't understand what do you mean by this. Adding extra configuration files? You are still able to do this, nothing changed for you unless you want better autodiscovery. >> I am of control. That's why god gave us ability to override. >> It seems you are not aware what I suggest. > > I fully understand what you are suggesting, you cannot seem to > comprehend someone understanding what you are asking for, and > disagreeing with it. You said a point that wasn't correct. I doubted you understood what I suggested. > One of your use cases for this is to allow a pluggable application to > specify it's own database settings, which is unthinkable to me. Ok, don't think about that use case then. With every weapon you can shoot yourself in a foot. Can't you do "from yourapp.settings import *" and can't that settings.py set a database for you? > Setting up, configuring and allocating databases is work for the > project manager, not for the application developer. > > Similarly for any number of other settings that can have profound > effects on the functionality of the app, eg: > TEMPLATE_LOADERS > MIDDLEWARE_CLASSES > ROOT_URLCONF > INSTALLED_APPS > TEMPLATE_CONTEXT_PROCESSORS > > and any number of project specific settings that an application may be > unaware of. The role of configuring a project is for the project > manager, not for the application developer. This is hardly rocket > science! You have special person for configuring a project. I'm configuring my projects myself. You are happy with your "solution", I'm not. I'm proposing a change that will make both of us happy. I'm telling that every project configuration have the same steps in its development. single file -> two files -> machine dependent config files. The same is for the app development: no app-specific options -> app specific options This evolution does never change its direction. I suggest a solution that I think might spread. Of the problem which is already widespread, but for which every project config developer uses different solutions. The solution is not obligatory, it's optional. Like everything in Django. You will still be happy. -- 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.
