On 08/07/06 18:39, limodou wrote: > On 8/8/06, Michael Radziej <[EMAIL PROTECTED]> wrote: >> >> limodou wrote: >> > On 8/7/06, Kevin Menard <[EMAIL PROTECTED]> wrote: >> >> On 8/7/06, Joe <[EMAIL PROTECTED]> wrote: >> >>> Wouldn't you want to put your database settings (Username and password) >> >>> in another file as well? >> >> I would be all for this. I never liked that the settings file >> >> contains both project-wide and user settings. Since it's >> >> project-wide, it gets added to the SCM. Since it contains user >> >> settings, users really shouldn't commit it back. I realize it's >> >> Python code and all that, but it seems to be a flaky default to me. >> >> >> > So I think secure data should be stored separately from project >> > settings. Maybe usename and password should be stored in separate file >> > also. But others don't need to do so. And if username and password >> > also be stored with secure key together, maybe the appoach what >> > Michael Radziej suggested need to be considered. >> >> In reality, you will have multiple deployments: production, >> staging, development, demonstration, depending on your company's >> policy and what your project is about. For each of these you want >> to use different databases, might have different middlewares >> (e.g. for different logging levels, or you >> might want the CSFR middleware not with your development server), >> etc. >> >> I strongly disbelieve that any fixed scheme of storing some >> settings separately will cover everybody's needs. It's easy >> enough to code your own thing in your settings.py. >> >> Michael > > So I think different things should be considered different. Just like > before, many people would say settings.py is only a pure python source > file, no one would stop you to change it, and make it suit for you. > That's right. And I think many people like me have done like this. But > I think a good framework must provide the enough flexibility, but also > a good way about how to do the right thing. If something are proved to > be the right and wonderful, why not bring it some spec-like things? > And if someone don't like this and he still can modify the source > code, and do what he want. I think if we can introduce such the best > practice principles in django, it's a good thing. > > And just like many people have said, if you should deploy the product, > you should think about how to deal with securekey, username and > password, that's right too. But if there is a default good appoach, > and it's proved to be good, why we don't use it, and let our head take > a rest. And I think I can learn many thinks from it. > > Just some thought. It maybe not correct. > > Why I bring this proposal, because I just saw thc settings.py in zyons > project, and I think it a good way, and I should admit that, I don't > think of it too much before. And I think there maybe many people don't > think of it carefully also. So I sumbit this proposal. That's all. >
Why not just create a second settings file, call it settings_local.py or whatever, and at the end of settings.py do something like: from settings_local import * That way you can have settings.py under source control with application wide defaults configured and override anything you like in settings_local.py for per user or per machine configuration. You can even have a settings_local.template under CVS with instructions to copy it to settings_local.py and change as required. IMHO a simple, flexible solution for the problem. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
