I've been checking out python-decouple and I have to say it's pretty easy, it replaces django-dotenv, django-getenv and django-autoenv for those working in a 12factorish way
2014-09-30 13:29 GMT-05:00 Arthur Alvim <arth.al...@gmail.com>: > There's a really nice project called python-decouple. ( > https://github.com/henriquebastos/python-decouple/) > > You can store you vars on .ini or .env files and ignore then on git. > Install > > pip install python-decouple > > <https://github.com/henriquebastos/python-decouple/#usage>Usage > > On your settings.py. > > 1. > > Import the config object: > > from decouple import config > > 2. > > Retrieve the configuration parameters: > > SECRET_KEY = config('SECRET_KEY')DEBUG = config('DEBUG', default=False, > cast=bool)EMAIL_HOST = config('EMAIL_HOST', default='localhost')EMAIL_PORT = > config('EMAIL_PORT', default=25, cast=int) > > > > > > -- Atenciosamente > - Arthur Alvim [ arth.al...@gmail.com ] > > IFPE - Tecnólogo em Análise e Desenvolvimento de Sistemas > UFPE CIn - Mestre em Ciência da Computação > > "Partilha os teus conhecimentos. É a forma de conseguires a imortalidade." > Dalai Lama > > > 2014-09-30 14:30 GMT-03:00 Vernon D. Cole <vernondc...@gmail.com>: > >> 12-factor is all the rage, and they have some very good ideas that ought >> to be followed. But insisting that environment variables are the only >> correct way of storing settings, is, well, just plain wrong. [ Note: I have >> 40 years of experience, I recognize a fad when I see it. ] All of those >> values have to get _into_ the environment variables somehow, and that means >> that somewhere there is a disk file which has them in it. Is it really >> safer to have them written in some language other than Python so that you >> have to have a special program to read them? I doubt it. >> >> So my preference is to use a structured settings arrangement, where the >> file which is referenced by DJANGO_SETTINGS_MODULE imports settings.py (not >> vice-verso). >> That outside settings module, called salt_settings.py on my systems, is >> written by the SaltStack "state" which deploys my server. >> The same "state" also creates the database, the nginx configulation, and >> the uWSGI configuration, so the same passwords, sockets, database names, >> etc, are used on both sides of an interface. >> The sensitive data, such as passwords, are kept in a Salt Pillar >> structure, which is in a (highly protected) repo, separate from the salt >> "state" files, which are in a separate repo from the application. Three >> purposes, three repos. >> >> Why SaltStack and not one of the other configuration engines mentioned >> above? Because Salt, like django, is written using a Python templating >> system. You do not program your configuration in Ruby (Puppet and Chef) or >> Python (fabric), but lay it out in nice, readable, white-space sensitive >> YAML files, with Jinja templates where needed. >> I have an over-simplified example at >> https://github.com/eHealthAfrica/salt_demo >> -- >> Venon Cole >> >> >> On Monday, September 29, 2014 2:05:37 PM UTC+1, guettli wrote: >>> >>> Hi, >>> >>> of course we separate data from code: >>> >>> - code belongs into version control (git) >>> - data belongs into a database (postgres) >>> >>> But where does configuration belong? >>> >>> Since I am a developer I like version control. >>> >>> But the longer I think about this question, I think >>> the perfect configuration for an app just contains >>> one entry: How to connect to the DB. >>> >>> Sooner or later you want things to editable via an admin interface. >>> >>> And if you look at big systems like SAP. There is only very little >>> config in files. >>> >>> I think config should be done in the database, not files. It is hard to >>> accept >>> this, since version control is great for files, and not so good for >>> databases, >>> but I think it is the way to go. >>> >>> What do you think? >>> >>> Thomas >>> >>> >>> >>> -- >>> Thomas Güttler >>> http://thomas-guettler.de/ >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-users+unsubscr...@googlegroups.com. >> To post to this group, send email to django-users@googlegroups.com. >> Visit this group at http://groups.google.com/group/django-users. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/f518e9ed-e22d-49d6-8f0f-5ef8981b6d88%40googlegroups.com >> <https://groups.google.com/d/msgid/django-users/f518e9ed-e22d-49d6-8f0f-5ef8981b6d88%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CANjJ3%3DMTW0euFcQiv3QPTV4oidHWay91uK7oviAU8_YF71CN4g%40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CANjJ3%3DMTW0euFcQiv3QPTV4oidHWay91uK7oviAU8_YF71CN4g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- *Jorge Andres Vergara Ebratt* *#SoftwareDeveloper (Or at least trying to be)* *@javebratt* *facebook.com/javebratt <http://facebook.com/javebratt>* -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAAeX05GKiL-kQsm7JFrE_68_JgHOpTx%3DP2UM48OdCJVt4JD%3D1Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
