Okay, I read it. I think that it argues for structured settings, not against them.
What I read was a set of guidelines, rather like the Zen of Python. They look like good, reasonable rules-of-thumb to me, and I have been around long enough to recognize such. One of the reasons I adopted Python was that I found my self in such complete agreement with the Zen the first time I read it. I particularly liked its built-in admission that there will be exceptions to its principles. Let's talk about three of these twelve. I have cut-and-paste-ed them from the web page. I. Codebase <http://12factor.net/codebase> One codebase tracked in revision > control, many deploysIII. Config <http://12factor.net/config> Store > config in the environmentX. Dev/prod > parity<http://12factor.net/dev-prod-parity> Keep > development, staging, and production as similar as possible Note that number three says "in the environment" not "in a large collection of operating system environment variables". Those are different things. More about that later. First, note that rule number ten works against rule number one. The reason that the codebase we call "django" gets deployed so often is because it is so flexible. The same codebase runs on a Windows laptop and a Java server in a dark server room. "As similar as possible" gets stretched a very long way. Yet the fact that I am actually running the same codebase in both situations means that there are a _lot_ of similarities - more than there are differences -- because the codebase is programmed to minimize the differences. But there must be a way to tell that large, flexible codebase what we need it to do today -- and today in django, that is done in settings.py. Other products have other methods of specifying their configurations. The database system I helped write in 1982 had a database-of-databases: you switched environments by specifying (using a command line switch or an operating system environment variable) which root database you were using at that moment. It eventually worked on eight different operating systems from RT-11 to Windows-32. Microsoft dotNET uses xml files stored alongside the executable files for their configurations. If you have ever had to modify one of those monsters, you will appreciate the simplicity of settings.py. At times, I have written Python scripts to modify the dotNET config files in place. Ugly! Then there is the Windows registry, lets say no more about that. The point is: configurations have to be stored somewhere. So how do we store them "in the environment"? 1) As multiple operating systems environment variables. Each operating system will need to be separately documented as to how to set environment variables. (Have you ever tried to explain that to a beginning Windows user?) Each *nix shell will also require separate documentation, and a separate shell script to set them. Here there be dragons! Or, perhaps, someone will write a Python script to set them all. :-o 2) In a pre-defined database-database, perhaps overridden by an environment variable or command line switch. 3) In a generic file with a known name, perhaps overridden by an environment variable or command line switch, in a format as yet to be defined and fought over. 4) In a Python file with a known name, perhaps overridden by an environment variable or command line switch, which can import more generic configuration files, which can import others, until a base standard configuration is reached. 5) In a Python file with a known name, perhaps overridden by an environment variable or command line switch, which may import another Python file with a known name, which cannot be stored in version control. Numbers three or four could be included in version control, and selected at run time as needed. I think that is a much more secure "environment" than a motley set of instructions of how to set environment variables in shell xyz, or how to encode some kind of URL giving the same information. Numbers four and five use a format already familiar to django users, and which is extensible so that more advanced methods of configuration setting (such as the two mentioned elsewhere in this thread) can easily be implemented, if desired. Number five is what we have today. I am suggesting number four. Did that sell anyone? -- Vernon On Thursday, September 26, 2013 12:45:20 AM UTC+1, Russell Keith-Magee wrote: > > > On Thu, Sep 26, 2013 at 4:21 AM, VernonCole <verno...@gmail.com<javascript:> > > wrote: > >> I find myself using up lots of time and keystrokes explaining about the >> benefits and methods of a structured settings module in django. >> For example: >> Using-a-Structured-Settings-environment<https://github.com/modilabs/formhub/wiki/Using-a-Structured-Settings-environment> >> >> It occurs to me that life would be easier if django shipped already set >> up for structured settings, rather than having to retro-fit it. The pull >> request I sent to formhub could be a starting point for the conversion. ( >> formhub/pull/1240) <https://github.com/modilabs/formhub/pull/1240> The >> changes to core are simple enough that I could do it. >> >> Your opinions please, Would such a change be good for django 1.7? >> > > Based on conversations that I had at the sprints at DjangoCon US, I'd say > probably not -- because the winds are blowing in another direction. > > The primary reason to need structured settings like this is because your > development environment is different to your deployment environment (e.g., > different passwords, paths and so on). > > However, the emerging best practice for this sort of thing is best > described by the "12 factor" approach: > > http://12factor.net > > Factors 10 and 3 are the most relevant to this discussion -- 10 says that > development and production should be the same; 3 says that anything that > needs to vary should be set as an environment variable, and consumed from > there. > > So - I'd expect to see Django moving towards better support for a 12 > factor environment, rather than embedding separate settings files as a > deployment practice. > > Yours, > Russ Magee %-) > > -- 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.
