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, andres....@gmail.com <javascript:> 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
