Config Inheritance

Continuing the topic from the previos post about project configuration, I would like to metion one more important thing. It’s a config inheritance or config overriding. I don’t want to argue if my approach is good or not. I just like it and I try to follow it wherever it’s possible.

I will write about possible configuration location in the order where the next level will override the previous one:

  • Default values in the code. It’s a common location for defaults if it’s possible. Sometimes you can’t have any default value due to the different reasons.

  • Config file in the default. I mean that you often have something like /etc/yourapp/yourapp.conf or a config file in the working directory. Nothing special here. It’s obvious that config files should override defaults from the code.

  • Additional config file. Sometimes it’s possible to provide several config files into your application. E.g.: /usr/local/bin/yourapp –config=/path/to/configA –config=/path/to/configB. In a such case, values from the configB should override values from the configA.

  • CLI arguments like /usr/local/bin/yourapp --paramA=1 --param2=2. Sometimes it’s extremely useful to have the ability to specify config options in such a way. E.g. you need to launch the second instance of your application just with a different database connection string or something like that.

  • Environment variable. It’s the most controversial item in this list, I guess. Somebody like it, somebody doesn’t. The argument against it is simple: it’s not explicitly passed to the application, so you can pass some wrong value by a mistake. E.g. some environment variable could be set by default when you’re logging in into some remote console. But I like it for the following reason: it’s easy to set an environment variable inside your session to override some options for each application call during the SSH session. Honestly, I’m not sure what should have the highest priority: environment variables or CLI arguments but for a consistency, I decided to have such order.


.net .net-framework .net-framework-3.5 agile ajax ajax-control-toolkit ampq ansible apache automation axum babel bash benchmark blog blog-engine bootstrap buildout c# cache centos chrome ci cinder ckan cli cloud code-review codeplex community config debugger deface dependencies development-environment devices devstack devtime disks django dlr dns docker dockerimage dos easy_install elmah encoding environment-variables error event events everything-as-a-code exception exceptions fabrik firefox flask foreach forms gae gcc gerrit git github go google google-app-engine grep hack hacked hardware headless horizon hound html hugo iaas ienumerable iis internet iptables iron-python ironic iscsi java-script javascript jenkins jquery js jsx kharkivpy kiss kombu kvm kyiv lettuce libvirt linux lio loci logging loopback losetup lvm mac-os macos mercurial microsoft microsoft-sync-framework mobile mono ms-office msbuild networking news nginx npm npx offtopic oop open-source open-xml opensource openstack openvswitch os packages paraller-development patterns-practices performance php pika pip plugins pnp podcast popup postgresql profiler project protocols pycamp pycharm pycon pykyiv pylint pypi python python-3 qcow quantum qumy rabbitmq rar react reactjs refactoring rfc rhel search-engine security selenium server shell silverlight socket software-engineering source-control sourcegear-vault sources sql sql-server sql-server-express sqlalchemy ssh svg tests tgt tipfy tornado typescript uapycon ui uneta unit-tests usability virtualenv visual-studio vitrage vm vue.js vuejs web-development web-server web-service web_root webpack webroot windows windows-live word-press x32 x64 xcode xml xss xvfb интернет-магазин книги


2019 (46)
2018 (2)
2017 (3)
2016 (2)
2015 (3)
2014 (5)
2013 (17)
2012 (22)
2011 (35)
2010 (25)
2009 (35)
2008 (32)
2007 (2)