Honestly, I find the idea of *not* using a settings file to be inconvenient, and the notion of using environment variables for doing anything aside from pointing to a settings file to be pretty disgusting.
Here are my thoughts, in no particular order: - Pretty much everyone out there uses some form of settings + local_settings.py for configuration, keeping the installation site-specific in the local settings, and checking in a local_settings.example.py file for instructions. This has never really been an issue for me except for database-specific content settings, which is not something environment variables solve. - The system environment variables is a flat namespace, completely polluted by different shell's variables, with high potential for unintended name clashes. - For development, reloading an env var does not reset the development server; I usually *want* the dev server to be reset whenever there's a config change. - You have to set your env vars from somewhere, adding an extra layer of indirection and complexity. - Not all shells have facilities to easily navigate settings; it's easier if they're stored in a startup shell file, but that offers no advantage from a Django file - I like the fact that you can use Python facilities like os.path.join to generate config variables on startup. On Thu, Sep 26, 2013 at 9:55 AM, VernonCole <[email protected]> wrote: > (Memo to self: always think about it for a day before replying.) > > Okay, I see. And I certainly agree that a few strategically placed > instances of (for example) > >>> psw = os.environ.get('DBPASSWORD', 'DumbDefault') > would help security in most cases. > > I will get back to the drawing board, then, and see if I can still get the > optimization I am looking for without making the system more difficult for > those who don't want it. > > My use case, is, I'm afraid, even more wrong than you suggest, Marc. I > develop on Linux, but have to plan for instances where unfortunate > individuals must deploy on Windows. Administrators of those systems are > often neophytes at systems administration in general and Python in > particular. Installation of something like envdir would be far beyond > hope. More frequent will be deployments by people who may know Windows > systems administration, but this will be their first experience with > Linux. Simplicity is everything. > > Thank you, everyone, for the quality input. > -- > Vernon > > On Thursday, September 26, 2013 11:26:01 AM UTC+1, Marc Tamlyn wrote: >> >> No, when 12 factor says in the environment, it means exactly that. *NOT* >> checked into version control, and in the environment of the shell. >> 12-factor is talking *only* about number 1 for differences in your >> environments. >> >> Yes windows is not very good at environment variables in general, but I >> would argue if you're developing on windows and deploying to *nix you're >> already doing it wrong. I refer you to point 10. You may however be >> interested in Jannis' python port of envdir - https://github.com/jezdez/* >> *envdir <https://github.com/jezdez/envdir> - which works on Windows. >> >> Personally, I find the multiple settings files (local_settings.py, >> structured settings) to be a pattern I'm moving away from, and I'm unlikely >> to support changes to Django encouraging it more. Jannis' configurations is >> a bit different, I find it's a nicer way of grouping your settings >> together, making them overrideable from external apps etc. The end game is >> still one settings file, with environment switches. >> >> The advantage of the current settings.py is that it's very simple and >> flexible, which allows these patterns to all work together. At some point >> we may change to another system, but I don't feel we should be actively >> encouraging any particular path at present. There isn't a clear consensus >> as to the best way forwards. >> >> >> On 26 September 2013 11:11, VernonCole <[email protected]> wrote: >> >>> >>> 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 <[email protected]> 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-**en**vironment<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-develop...@**googlegroups.com. >>> To post to this group, send email to django-d...@**googlegroups.com. >>> Visit this group at >>> http://groups.google.com/**group/django-developers<http://groups.google.com/group/django-developers> >>> . >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<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. > For more options, visit https://groups.google.com/groups/opt_out. > -- Andrés Osinski http://www.andresosinski.com.ar/ -- 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.
