[kyllo]

Steve Yegge wrote a blog post about this a few years back that I found eye-opening.

The whole nasty "configuration" problem becomes incredibly more convenient in the Lisp world. No more stanza files, apache-config, .properties files, XML configuration files, Makefiles — all those lame, crappy, half-language creatures that you wish were executable, or at least loaded directly into your program without specialized processing. I know, I know — everyone raves about the power of separating your code and your data. That's because they're using languages that simply can't do a good job of representing data as code. But it's what you really want, or all the creepy half-languages wouldn't all evolve towards being Turing-complete, would they? https://sites.google.com/site/steveyegge2/the-emacs-problem

[davexunit]

Great quote. This idea is still not too popular, unfortunately. There are a lot of folks out there that get real mad when configuration is code. Notably, sysadmins that feel forced to learn Clojure or <insert-language-here> to configure an application. "Why not XML or JSON?", they say.

[Goladus]

Most well-designed applications will separate the administrative interface (configuration) from a programming interface (the API), even if the same langauge is used for each one. If you do this properly, most administrators are not going to care what language your configuration is in so long as it's clear and consistent.

In my experience, the main annoyance using programming languages for configuration is the need to use explicit string literals for every string in your file. List separators are another major source of clutter in configuration files, though this is theoretically not a problem in clojure. The second problem is the tendency to be undisciplined and allow too much program logic in configuration files resulting in complex and unclear relationships between options and behavior.

Personally I do all my configuration in yaml now. Even if I was using lisp I would use yaml whenever possible for configuration and static resource definitions, because yaml is very portable.

[kyllo]

It really depends on the environment and culture. In Python web apps for example it's very popular to keep project configuration in Python dicts and lists, which are just Python code (as opposed to using something like YAML or JSON for config).

[hcarvalhoalves]

Popular, but an anti-pattern. People start including production configuration as a module inside the build.

The Right Way (TM) is loading from env vars.

[kyllo]

By "inside the build" do you mean in the git repo?

Because there isn't really a such thing as a "build" for a Python web app, it's a dynamic language. It's not like Java where you'd have to recompile the whole app if you packaged your config inside the compiled jar.

In Django apps, there's an env var called DJANGO_SETTINGS_MODULE that points to one of multiple settings.py files, and you change that var depending on which environment you're working in. Then typically you also would want to store individual variables that need to be secure (stuff like any secret keys and database credentials) in env vars, but the overall structure of your config is just a python dict in settings.py.

For reasons that Yegge touches on in the blog post I linked above, you really want a tree structure for configuration of any complexity, and env vars don't provide that.

[Goladus]

I think he means that the configuration file is on the library path is read using an import statement rather than parsed explicitly from a standard path like etc/.

[warfangle]

Well, technically, JSON is just a Plain Old Javascript Object, with restrictions (no expressions, quoted keys).

[kyllo]

Sort of, at least in the sense that you can eval JSON from JS code rather than having to parse it yourself. This is one of many language concepts that JavaScript cribbed from the Lisp/Scheme family of functional languages.