On 8/8/06, Steven Armstrong <[EMAIL PROTECTED]> wrote:
>
> 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 *
So what you do just like what I'v said:
"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 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.
>
The problem is not I don't know how to deal with secure-key right. And
my proposal already gives a solution:
SECRET_KEY = file('.key', 'rb').read()
And I think it's a good way.
The problem is : different people will give different solution, and I
already have seen many in this thread:
1)SECRET_KEY = file('.key', 'rb').read()
2)using ini file --- from Michael Radziej
3)settings_local.py --- Steven Armstrong
Maybe more. So which one is the best, and whether it can be used in
django as a default solution? And whether we need a good solution? Or
we don't need it at all, there is no such a default solution, you can
do everything as long as you can find out a way?
I guess the most of answers maybe : we don't need it at all. If that's
true, I should be the fewness who want a default good solution. That's
it.
--
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
-~----------~----~----~----~------~----~------~--~---
