Comments on: Configuration Options in Code or INI Files?

By: zaur

zaur — Fri, 19 Dec 2008 18:53:12 +0000

Last time I been considering a Python Object Notation (PyON). It bases on python syntax. It could be considered as readable reconstructable representation for python objects. It dosn’t use eval/exec for reconstruction; it bases on AST interpretation. I think it could be usefull for configuration purposes.

http://code.google.com/p/pyon/

P.S. PyON project is very young but you already able to do interesting things

By: sage

sage — Tue, 09 Dec 2008 08:32:32 +0000

I definitly use yaml too instead of ini files.
yaml is easier to read than json (while every json file should be read by a yaml parser too)
yaml is easier to abstract complex structure than ini files.

By: Cory

Cory — Mon, 08 Dec 2008 17:41:44 +0000

I think you’re missing the most important reasons to use ini files, although you kind of dance around it.

The reason not to use code is because ini files are not code. This is important. INI files are a declarative syntax; they cannot have ifs or loops. Files that have a pure-declarative syntax have the following advantages:

- they can be losslessly transformed into another format (including code). Code files do not have this advantage; there’s always the risk that they contain an if block, which means you need an interpreter with a loaded namespace and runtime environment to understand them.

- they can be machine-edited. Code can’t be machine edited in the general case, see above. You will want this if your package needs to be packaged in a .deb or .rpm for example; upgrade scripts take care of making edits around your users’ changes.

- They can be safely transferred (provided you filter out passwords). Sending code over a wire is risky to the person receiving it, who must then interpret it. Declarative ini files aren’t code, and can be safely parsed.

By: Kevin

Kevin — Mon, 08 Dec 2008 17:11:58 +0000

It’s python, do both. Write your INI in Python – keep the config separate from the code, but also keep it in code. Just import the config file. For long running daemons you can attempt to reload the file every x minutes or some such. This allows you to update your config without touching the application code, but gives you the power of Python for storing your config info in Dicts and such.

By: Marcos Dione

Marcos Dione — Mon, 08 Dec 2008 15:51:16 +0000

ini files are really the wrong solution for complex things. see, config files are mostly a way to reprogram a certain tool; it’s like the switches in the first programmable computers. implementing complex decisions with switches is difficult. for those cases I prefer coding your own decisions. an example I’m toying with right now is a email server; it’s routing table is complex enough to be more simple to implement by code rather than switches.

By: mkay

mkay — Mon, 08 Dec 2008 14:50:21 +0000

+1 on options in code

Most “options” aren’t really options at the office. Some, like the Java class we should use to do X don’t have any other values, but the argument is that “someday we’ll need that”. Usually they are instances of over-engineering.

I opt for the opposite and write straight-forward code. When something needs to become an option, then I move to a configuration file. Anything outside of the code needs a *lot* more documentation, maintenance, QA, etc.

By: James Thiele

James Thiele — Mon, 08 Dec 2008 14:42:57 +0000

-1 on config options in code.

Big downside is merging changes.

Alice writes a program and gives copies to Bob, Carol, Dan and Ellen. They all edit their copies for personal config options. Alice finds a bug and sends out a new version. Now everybody has to do a diff/patch cycle. If the config options were in a seperate file they’d just drop in Alice’s new code.

By: bc

bc — Mon, 08 Dec 2008 13:08:41 +0000

OK, I checked. PyYAML has a “safe_load” function which will only create basic types, hence avoiding the security-risk of loading an untrusted file which could create a malicious object.