To all of you who don't see benefit in putting certain (definitely not all!) settings in the environment, I would like to say: try it. It will finally make sense that you set DJANGO_SETTINGS_MODULE in the first place. I never understood why anybody would want that until this :D.
I was sceptical first as well, but tried out Heroku and therefore this method. I have since converted all projects to a structure where environment specific variables are stored, well, in the environment. Still my settings is a module, where prod.py and dev.py inherit from common.py, but that is mainly because certain apps are not necessary on either dev of production servers. So that is all checked into the repository. I don't see any necessity to store those environment vars in a repository, as they contain login keys and static files buckets etc. On the production server I find it logical that you define those vars in the config files that also make the app run (those of gunicorn or supervisor for example). Changing an AWS bucket or database is not something related to the code history in the repo, but it is to the configuration of the app in the environment. On the development side, I currently have alias wenv="eval $(echo '$(cat .env) $1' | tr '\n' ' ')", all variables in a .env-file, and run commands like wenv python manage.py syncdb. I recently stumbled upon envdir[1], but I still miss some features to make it complete. Honcho[2], a python port of Foreman (that what Heroku uses) is a procfile based application manager that also loads variables from .env files is also a way to pick those up, if you run on Heroku for production for example. Tino [1]https://github.com/jezdez/envdir [2]https://github.com/nickstenning/honcho On Sat, Sep 28, 2013 at 11:07 AM, VernonCole <[email protected]> wrote: > Not off topic at all, Carl, this back-and-forth is helping me, at least, > consider some new things. > > Here's what I have learned from this discussion so far: > > 1. Clearly, any change needs to avoid use of the word "structured", since > that is now yesterday-ish. > > 2. Any change needs to lead toward and encourage and/or ease use of 12 > factor methodology. > > 3. The settings.py file needs to stay where it is and do what it does > without much change. > > 4. There is a quiet wish for something better than the status quo, but it > must be flexible enough to allow new and different advanced solutions. > > 5. It needs to be simple to use for development, demo, test, tutorial, and > semi-skilled implementations. > > 6. A URL-like scheme might be a good default option. > > The original idea with which I started this thread miss-fired on points > one and three, and I was completely unaware of point two. Point six was > something I had rattling in the back of my mind for years, but could not > envision a way to do it -- especially with something as simple and elegant > as Kenneth Reitz's work. > > So I started mucking around and I like the emerging design much better. I > have received a bit of positive feedback on it already, and I think I may > have found a decent compromise where practicality and purity can co-exist > as multiple example files, and the implementer can pick from them his own > best options. I have several example files there now, which effectively > replace the not-verbose-enough commentary in settings.py which tries to > tell how to set up the DATABASES dictionary. They include working examples > which I use for actual testing against multiple db engines. (My intranet is > like my house: just enough security that breaking in is not trivial, and > nothing inside worth stealing.) Since each of the small, individual > examples is simple, I have started to add 12-factor features (like getting > a password from the environment) to some of them. I will add samples of at > least one "pure" 12-factor method. I may decide to use a version of > dj-database-url as the default. > > I moved settings.py back where it belongs. Since the folder with the > examples cannot also be named "settings", I renamed it "preset". So, > presently, my modified manage.py sets the default value of > DJANGO_SETTINGS_MODULE to "formhub.preset.default_settings". > > As always: any suggestion is welcome. > -- > Vernon > > On Friday, September 27, 2013 11:07:28 AM UTC-6, Carl Meyer wrote: > >> On 09/27/2013 10:52 AM, [email protected] wrote: >> > What is the difference between privately tracking a shell file and a >> Python config file? >> >> Not a lot of difference, but the env vars give you more flexibility. In >> a single settings file using env vars, I can easily have things like a >> "mode switch" in a single env var that affects the defaults for a number >> of related settings, without having to repeat myself on redefining all >> those settings. That kind of thing is harder to do cleanly when you're >> "inheriting" one settings file from another using "from settings.base >> import *", or using local_settings.py. >> >> (Since I don't think Django core is going to take any steps to endorse >> any particular approach to handling settings anytime soon, I think this >> discussion is really off-topic and should move somewhere else. I should >> have considered that before replying to Tom.) >> >> Carl >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANQFsQA6gbXc3hVADNUv_pdrRkjRvPewBpc8Y06_O2POqaEJ_Q%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
