Config files: better without logic

AKA: Why Ruby isn’t, and will never be, a configuration format

Using Ruby as a method for storing configuration data is increasingly common. Instead of having YAML, JSON, XML (oh god pointy) or INI (lol) files storing your lovely little configuration bits, we can start dumping all our data into Ruby, using hashes or DSLs. The author of configatron has astutely noted that if you use Ruby to store configuration, you can have Procs in your configuration files!

So wait, wait, let’s take a step back and ask the question - when did a Proc become configuration data? Do we really need the ability?

Seriously, by the time you need a Proc as config data, I’m pretty sure you’re doing something wrong. It may seem easier in the short run - harness all the power of Ruby in your configuration - but after a while, you start getting little applications in your configuration. Suddenly, these little applications become big applications, and then the gates of Sheol crumble and the undead swarm up to join the living - wait, maybe not that but. But still, it’s messy and invites abuse.

If you need to either run your config files through ERB or use straight Ruby, you have deeper problems. If you’re prototyping something and just need a quick way to get config data in this is a good way to get a lot of flexibility right away, but as mentioned earlier it isn’t a good long term solution for configuration. While you give people a way to hack around the limitations, it’s a cop out and avoids addressing the underlying problems.

On top of that, what happens when your configuration is malformatted? OH GOD RUBY SYNTAX ERROR UNEXPECTED ‘)’ EXPECTING ‘}’ BLARRRRRGHHHH STACKTRACE. You don’t get a neat “Hey, you done wrote some bad config there, howzabout you do that right next time.” (Admittedly you could do a begin/rescue LoadError, <tangent>but it seems like the Ruby solution to things like this is fail hard and produce Java-esque stacktraces. </tangent>)

We’re seeing template systems that are eschewing logic, EG mustache. Putting logic in your views in general is considered A Bad Idea (TM). With this sort of approach, why are we moving towards more logic in configuration files? There’s definitely a time and place to really throw raw power into the mix and allow for serious computation, but config files seem to be the wrong place. After all, configuration should store data, not code.

If you really do need this sort of logic, then provide a well formatted way for people to do more complex things. Expose the configuration system for people to extend, but don’t force people to use ruby. Perhaps add a plugin system that people can use to add more dynamic behavior. You’re more likely to see these sort of extensions filtering back which you can then incorporate, instead of unholy config files floating about.