Forgive the slight tangent, but I think it's important to understand why settings are defined in Python and not a markup language (like some RoR settings are). It's a very intentional design decision that gives developers the flexibility to define settings in a way that makes the most sense for their project (with the help of a programming language). That is *powerful*. It means that:
- If you want to store settings in a markup language, all you have to do is write an adapter. - If you want to put settings in a database, you can do that too (but you're probably doing it wrong). - Or, as most people do, you can define them in pure Python. However, that flexibility isn't solely restricted to the method of defining settings; it could also be applied in the selective determination and loading of settings. Now, consider the problem you're trying to solve. It will work great on simple sites that have one development server and one production server. However, if it is implemented we would be forcing a specific server setup and workflow on Django's users, and not all Django projects are deployed in the same way. What if you also having a staging server that QA checks are made on? What if you have 3 production servers that are load balanced, each of which are optimized in different ways and thus require different settings? Django's settings are able to accommodate edge cases like this because they are generic and flexible. You have the power to (and should!) find a solution that makes sense for your project, as it seems you've done. However, that sort of thing belongs in a project, not in Django itself. On Fri, Sep 24, 2010 at 1:01 PM, 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<django-developers%2bunsubscr...@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<django-developers%2bunsubscr...@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<django-developers%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- * --- Chuck Harmston* ch...@chuckharmston.com http://chuckharmston.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.
