Chuck - Thanks. Perhaps there isn't such room for improvement on the topic.
Jacob - It appears to me that you don't read things before you comment on them. That's two times in one post. Patience is a virtue, my friend. On Sep 24, 3:12 pm, Chuck Harmston <ch...@chuckharmston.com> wrote: > My technique, which allows you to: > > - Segregate settings per environment > - Keep environmental settings under version control > - Have multiple environments on a single host (using an environment > variable set by the WSGI script) > - Keep passwords and other sensitive information out of source control > - Conditionally modify settings based on the value of settings.DEBUG > > https://gist.github.com/5e0e3d58e92f7530b396 > > Feel free to steal/modify/improve as you wish. > > At this point, I think we're veering into django-users territory. Let's > bring it over there unless someone still feels strongly about Yo-Yo Ma's > original suggestion. > > On Fri, Sep 24, 2010 at 4:58 PM, Simon Meers <drme...@gmail.com> wrote: > > If everything is under version control, you'll need to detect the server > > status somehow. Some options: > > - check the absolute path of the settings file on the filesystem if you can > > ensure this path is different on the production server > > - import socket; and check socket.gethostname() > > - check for "runserver" in sys.argv > > - etc. > > > On 25 September 2010 06:50, Yo-Yo Ma <baxterstock...@gmail.com> wrote: > > >> What if I want dev settings in version control? > > >> What if I want "explicit"? > > >> On Sep 24, 11:09 am, "burc...@gmail.com" <burc...@gmail.com> wrote: > >> > 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<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 athttp:// > >> 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<django-developers%2bunsubscr...@googlegroups.com> > >> . > >> For more options, visit this group at > >>http://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. -- 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.
