I don't think there will ever be a true consensus. I predict that the
option that would leave the least number of people unhappy is a settings
API that allows for 3rd party settings backends. Having settings in the
environment is ideal for deployments, but what each project and admin
consider to be the environment will probably not be the same.
Adding support for a settings API shouldn't be too difficult (tm).
LazySettings gives us a nice place to hook in and import a 3rd party
SettingsBackend. DJANGO_SETTINGS_MODULE already defines a workable way of
choosing which settings to load. We'd need to define a way of structuring
its value to specify which backend to load and provide it with enough
information to get going. A URL format would work well for almost every
type of settings backend that I could think of. In addition to the same
basic settings behaviors, a SettingsBackend would need to add reload() and
save().
Is rough idea worth pursing? If so, I'll be happy to spend time
brainstorming and prototyping it. Settings have been a very annoying pain
for me for many years.
Regards,
Michael Manfre
On Thu, Sep 26, 2013 at 9:21 AM, Andres Osinski <andres.osin...@gmail.com>wrote:
> 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 <vernondc...@gmail.com> 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 <verno...@gmail.com> 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 <verno...@gmail.com>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 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.
>>
>
>
>
> --
> 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 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.
>
--
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.
