text: Often when starting a new Python project we need to spend some time thinking about how to manage the settings, decide on which module the configuration manager will be written, decide which name to give to this module, create a class or function to store the configuration keys, create the conditions for multiple environments and still need to worry about where these keys will be stored and in which file format?
  No more! now you have Dynaconf!
  Spend your precious time developing your application, run
  pip install dynaconf and let Dynaconf take care of your settings.
  Quick start.
  from dynaconf import settings
  And that's it!
  That is the only line of code you need, no complicated boilerplate, no hadouken-ifs, no need to maintain config classes.
  You must be wondering - "What magic is this? Where does the setting values come from?"
  Well, there is no magic, and the values can come from wherever you want, by default and following the recommendations of the 12 factor apps Dynaconf has preference for environment variables.
  # optionally you can save it in .env file export DYNACONF_DEBUG=true export DYNACONF_NAME=Bruno
  # app.py from dynaconf import settings if settings.DEBUG is True: print(settings.NAME)
  $ python3 app.py Bruno
  And the environment variables for Dynaconf are typed using the
  tomlformat so
  truehas been evaluated to boolean
  Trueand this makes it possible to export lists, dictionaries, floats, booleans, and so on.
  More than environment variables
  Well, that's cool, but your project will not have settings coming from just the environment variables, I'm sure you want to have a settings file where you can set default values.
  Dynaconf can read multiple file formats, out of the box it supports
  .py,
  .toml,
  .ini and
  .json. If
  PyYAML is installed then it will also support
  .yaml and you don't have to take care of finding and opening the files. The preferred format is
  .toml because it is currently the best configuration format, widely addopted, and you can use whatever file format you want.
  # settings.toml [default] name = "Bruno" [development] debug = true [production] debug = false
  # app.py from dynaconf import settings if settings.DEBUG is True: print(settings.NAME)
  $ python3 app.py Bruno
  And as you can see now using
  settings. file we can have separate
  [environments] by default dynaconf will always work on
  [development] which means only
  [default] and
  [development] variables will be loaded. At any time you can do
  export ENV_FOR_DYNACONF=production and then it starts using the values from
  [production] environment.
  If you don't want to have that separation by environment, you can simply put everything under
  [default]section.
  Read more about environments and settings file
  Some values are secrets
  A good practice is to not store your secrets like passwords and tokens directly on settings files, because you can make a mistake and commit that to a public git repository, so there are some alternatives to store secrets
  Environment Variables
  Not recommended
  There are some people who disagrees and it is really a point of security failure. However, if you are sure that your machine is protected, you can leave the secrets in the variables, at your own risk, Dynaconf can read it normally.
  Secret files
  This is a simple level of security for keeping secrets, and it is specially useful to keep
  development secrets. That token you use to access the development API etc.
  It is very simple, together with your normal
  settings.toml you put a new file called
  .secrets.toml and store your sensitive data there. Dynaconf will read it after the read of the
  settings.toml
  Wait.. how does it solve my security problem?
  Well it does not (yet) but it make your life easier in 2 ways.
  - Put
  .secrets.*in your
  ~/.gitignoreso you will never commit the mistake of sending that data to a public git repository.
  - Dynaconf can output debug information when
  DEBUG_LEVEL_FOR_DYNACON=DEBUGis exported, all loaded values are printed but if the values comes from a
  .secrets.*file, then only the key is printed and the value is masked. It is useful to use on public CI.
  - You can setup a step on your Ansible deployment playbook that will safely copy or generate the secrets file to store there on your production environment.
  You can also tell Dynaconf to load that file from somewhere else
  export SECRETS_FOR_DYNACONF=/path/to/secrets/location/.secrets.yaml (very useful for CI like Jenkins)
  Vault Project from Hashicorp
  Recommended!
  Now we are really talking about true security
  Using Vault is the better way to protect your secrets dynaconf has built-in support:
  export VAULT_ENABLED_FOR_DYNACONF=true export VAULT_URL_FOR_DYNACONF= export OTHER_VAULT_CONFIGS
  And then if have for example the
  TOKEN stores on your vault server you can simply do:
  from dynaconf import settings perform_your_authentication(settings.TOKEN)
  Vault has lots of features like leases and sealed vaults.
  Are you using Django or Flask?
  Dynaconf provides extensions for those 2 frameworks, with 2 lines of code you enable it and then your framework will start reading settings from Dynaconf.
  Django
  # settings.py import dynaconf # noqa settings = dynaconf.DjangoDynaconf(__name__, **options)
  Now you if you do
  export DJANGO_FOO=BAR you can access inside your app via
  django.conf.settings.FOO
  Flask
  # app.py from dynaconf import FlaskDynaconf FlaskDynaconf(app, **options)
  Now you if you do
  export FLASK_FOO=BAR you can access inside your app via
  app.config['FOO']
  What if you are using a different settings file format? a different framework and a different external storage?
  You can extend Dynaconf adding new loaders!
  Dynaconf already provides loaders for:
  .py
  .json
  .yaml
  .toml
  .ini
  - Redis Server
  - Vault Server
  .envfiles
  - Environment variables
  But if this is not a fit for your project you can still create your own loader
  Conclusion
  Dynaconf is the only thing you need to manage your settings!
  - Well tested
  - Trusted by companies like Red Hat, Seek, Catho and others
  - Well tested both on Linux and Windows.
  Read the docs
  Settings are simple but Dynaconf provides even more features like Feature Flags, Settings Context Managers, Plugin Settings etc..
  Documentation:
  Dynaconf is waiting for your feedback and Contribution
  :)
  from dynaconf import settings settings.THANKS_FOR_READING