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. -- I like python! My Blog: http://www.donews.net/limodou My Django Site: http://www.djangocn.org NewEdit Maillist: http://groups.google.com/group/NewEdit --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
