How it's better from both of the following:
1)
try:
from dev_settings import *
except ImportError:
pass
2)
if DEBUG:
from dev_settings import *
Because to have "project.is_dev" you'll have to write it somewhere already!
It's bootstrapping problem.
On Sat, Sep 25, 2010 at 12:01 AM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
> I read that article. The problem is that it's deployment specific. I
> dint even know what host name "omh.cc" is, but I have a feeling that
> you couldn't work on that from your laptop to your desktop without
> changing something. What I propose isn't a is_production variable. I'm
> proposing an explicit is_development variable so that I can choose my
> settings "explicitly" instead of trying to import something and then
> something else if that's not there. That is very un-pythonic. If I can
> say something to the effect of:
>
> if project.is_dev:
> import dev_settings
> else:
> # is live
>
> just example. I'm not suggesting "project" as a global. It's just to
> show the type of setting I want.
>
> That's much cleaner, and far more explicit than "import os, socket,
> etc".
>
>
> On Sep 23, 7:41 pm, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
>> Thanks for the link David. I'm gonna check it it now.
>>
>> On Sep 23, 6:16 pm, "David P. Novakovic" <davidnovako...@gmail.com>
>> wrote:
>>
>>
>>
>> > This link and the comments suggest some good stuff... particularly the
>> > comment from Malcolm and the original post.
>>
>> >http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p...
>>
>> > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic
>>
>> > <davidnovako...@gmail.com> wrote:
>> > > The thing is, in production mode you normally have to define where
>> > > your settings are anyway, so you pass the unusual settings file name
>> > > there, and just use the regular settings.py for your development.
>>
>> > > So then you are passing the settings configuration information once in
>> > > the production server's configuration, not every time you run your
>> > > development server.
>>
>> > > I think people with any decent sized project have addressed this issue
>> > > in their own way that suits their own needs.
>>
>> > > For example we have lots of settings files and just import the
>> > > relevant settings into a final file.
>>
>> > > For testing I do what i mentioned in my previous email.
>>
>> > > Like anything on here, you need to ask whether what you are suggesting
>> > > would actually be better off as part of the core or if it works just
>> > > fine as something that people can choose to use themselves...
>>
>> > > I think most people use whatever system they are happy with and it
>> > > doesn't get in the way of deployment/development. Thus this fails to
>> > > meet one of the critical requirements for consideration for inclusion
>> > > into core.
>>
>> > > D
>>
>> > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma <baxterstock...@gmail.com>
>> > > wrote:
>> > >> Thanks David, but I'm talking about having something built in. For
>> > >> instance, passing a variable to the "Development" server to tell it
>> > >> you're in "Development" seems a bit redundant, no?
>>
>> > >> On Sep 23, 3:39 pm, "David P. Novakovic" <davidnovako...@gmail.com>
>> > >> wrote:
>> > >>> As for running different configs:
>>
>> > >>> manage.py runserver --settings=settings_test
>>
>> > >>> etc..
>>
>> > >>> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss
>> > >>> <ja...@jacobian.org> wrote:
>> > >>> > On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma <baxterstock...@gmail.com>
>> > >>> > wrote:
>> > >>> >> I'm simply proposing the idea of having the development server
>> > >>> >> explicitly set something to indicate a "in development" status, so
>> > >>> >> that if that does not exist you can make the assumption that the
>> > >>> >> project is live.
>>
>> > >>> > This is exactly what the settings.DEBUG flag is for. Use it. Love it.
>>
>> > >>> > Jacob
>>
>> > >>> > --
>> > >>> > You received this message because you are subscribed to the Google
>> > >>> > Groups "Django developers" group.
>> > >>> > To post to this group, send email to
>> > >>> > django-develop...@googlegroups.com.
>> > >>> > To unsubscribe from this group, send email to
>> > >>> > django-developers+unsubscr...@googlegroups.com.
>> > >>> > For more options, visit this group
>> > >>> > athttp://groups.google.com/group/django-developers?hl=en.
>>
>> > >> --
>> > >> You received this message because you are subscribed to the Google
>> > >> Groups "Django developers" group.
>> > >> To post to this group, send email to django-develop...@googlegroups.com.
>> > >> To unsubscribe from this group, send email to
>> > >> django-developers+unsubscr...@googlegroups.com.
>> > >> For more options, visit this group
>> > >> athttp://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
