On 08/07/06 19:27, limodou wrote:
> 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."
>
> :)
>
yup, having python config files is way coool :)
>>
>> 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.
>
IMHO this is something that belongs in a FAQ or something like that, not
in the official documentation or even source.
A user starting with django, following the tutorials and such, doesn't
care about these kind of questions. Once he's played a bit with django
and decides to use it for a larger app he will (maybe) think about these
problems and go looking for a solution. Then the infos should be easy to
find, e.g. in a FAQ or wherever.
Longtime django users probably already have their own way of handling this.
just my 0.002
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
