On 08/08/06 02:46, Malcolm Tredinnick wrote:
> On Mon, 2006-08-07 at 14:22 -0400, Kevin Menard wrote:
>> On 8/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>>
>> > We don't need a default solution for this. It's not within the scope
>> > of this project to tell people how they should organize
On Mon, 2006-08-07 at 14:22 -0400, Kevin Menard wrote:
> On 8/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> > We don't need a default solution for this. It's not within the scope
> > of this project to tell people how they should organize their settings
> > files. Take that opportunity to
On 8/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> The thing is, there's no foolproof distinction between what settings
> should differ for dev environments and which ones are definitely for
> production environments. You gave the examples of MIDDLEWARE_CLASSES
> and ROOT_URLCONF, but those
On 8/7/06, Kevin Menard <[EMAIL PROTECTED]> wrote:
> Please see my message later is this thread that clarifies a bit. As
> an example, I would consider database settings to be a user-based
> setting whereas something like MIDDLEWARE_CLASSES or ROOT_URLCONF to
> be project-wide.
>
> To me it seems
On 8/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 8/7/06, Kevin Menard <[EMAIL PROTECTED]> wrote:
> > 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 contai
On 08/07/06 20:35, Michael Radziej wrote:
> Steven Armstrong wrote:
>
>> 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 *
>
> Well (apart from Adrian has put out his word no
On 8/7/06, Kevin Menard <[EMAIL PROTECTED]> wrote:
> 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 re
Steven Armstrong wrote:
> 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 *
Well (apart from Adrian has put out his word now ...), my problem
was that I had to build a debian pa
On 8/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> We don't need a default solution for this. It's not within the scope
> of this project to tell people how they should organize their settings
> files. Take that opportunity to showcase your individualism.
With the lack of an endorsed conven
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, Jo
On 8/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 8/7/06, limodou <[EMAIL PROTECTED]> wrote:
> > 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
On 8/7/06, limodou <[EMAIL PROTECTED]> wrote:
> 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 fin
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:
> >> >>> Would
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)
>> >
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 b
On 8/7/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> 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.
You'll never cover everybody's needs, but you can cover the vast
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 bo
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-w
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
Hi,
this type of questions, that seems to come again and again, can
be solved for example by having an ini-style file of deployment
specific settings somewhere and reading them in your settings.py
file. An example implementation is attached, and here's an
example of how the ini file could look lik
Wouldn't you want to put your database settings (Username and password)
in another file as well?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django
The other benefit of what limodou proposes is that is makes it really easy to generate anothersecret key when it is required.for example I've got 4-5 sites using basically the same settings file. when I want to create anotherI usually just copy the settings file, and alter the cookie name and secre
On 8/5/06, limodou <[EMAIL PROTECTED]> wrote:
> When you create a new project, django-admin.py will create a
> SECRET_KEY and saves it in settings.py. Sometimes we are developing an
> open source project, so we'll bring settings.py to public also. And
> also make SECRET_KEY openned. So I think if
On Sun, 2006-08-06 at 09:41 +0800, limodou wrote:
> When you create a new project, django-admin.py will create a
> SECRET_KEY and saves it in settings.py. Sometimes we are developing an
> open source project, so we'll bring settings.py to public also. And
> also make SECRET_KEY openned. So I thin
When you create a new project, django-admin.py will create a
SECRET_KEY and saves it in settings.py. Sometimes we are developing an
open source project, so we'll bring settings.py to public also. And
also make SECRET_KEY openned. So I think if django-admin.py could
create a file(maybe .key or key
25 matches
Mail list logo
