Let’s say goodbye to YAML for configuration, shall we?
I have to ask a question to my fellow Rubyists out there? Why are you still using YAML? I know why you think you like YAML. You think it’s a great way to write configuration files, but it’s really not. You know what’s a great way of writing configuration files for Ruby apps? RUBY!
I know it’s crazy, isn’t it? But why not? Why would you not want to use Ruby for configuring your applications instead of YAML?
I’m the maintainer of a pretty popular configuration tool for Ruby apps, Configatron, so I think I have a little experience in this field. I also write and maintain a lot of libraries that require configuration and I have never thought that YAML is the best way to do this.
Let’s look at an example of what a library developer has to do to load a YAML file to get configurations:
foo: barrequire 'yaml'config = YAML.load(ERB.new(File.read('/path/to/config.yml')).result)I don’t know about you, but I think that’s kind of lame. Most everybody runs their YAML files through ERB so that they can make their YAML files more ‘Ruby-ish’. Why not just use Ruby?? Here’s the same example in Ruby:
SomeLibrary.config = {:foo => :bar}require '/path/to/config.rb'In addition to not having to deal with all the whitespace, tabs, crazy nesting, etc… that YAML brings we get to use the full power of Ruby for our configurations! Try storing a Proc in YAML. Yeah, that’s what I thought. You can drive configurations from the database, environment variables, crazy equations, etc… the world is your oyster. All you need to do now is stop using YAML!
I’ve decided to drop YAML support in Configatron 2.9 (coming sometime this Summer) and I encourage all other library developers to do the same. It’s just not needed, or very nice for that matter. Now, if we can only get Rails to drop the database.yml file, I think we’ll be all set.
Ps. Make sure to check out my app FluxTracker.com for all your issue, project, and error tracking needs. Also check out TweetKO.com for backing up and bookmarking your favorite tweets.
Tags: configatron, rails, ruby, yaml
June 28th, 2011 at 1:41 pm
But if I did that, then I wouldn’t be able to read my database configuration file from the legacy parts of my app that are still in PHP. Long live database.yml!!
June 28th, 2011 at 3:31 pm
we use yaml as a replacement for xml in our config files, because those files will be read by ruby and java. if those config files were written in ruby, how will java read them??
if your project files will never be read by antyhing other than ruby, its ok to write those configs in ruby.
June 28th, 2011 at 3:43 pm
I don’t see what is wrong with YAML? Well, there is definitely something wrong with the Syck parser. However, YAML is great for representing key-value primitive data. It’s actually very easy to represent arbitrary blocks of text in YAML (http://bit.ly/lwwCSb). YAML ships with every Ruby environment, no dependencies needed.
As for loading Procs or other arbitrary instances of Classes, checkout ObjectLoader (http://github.com/postmodern/object_loader).
June 28th, 2011 at 11:32 pm
If data is in rest, is meant to be read by a human but parsed by a machine, then it should be in YAML.
> Most everybody runs their YAML files through ERB so that they can make their YAML files more ‘Ruby-ish’.
No, people run YAML files through Ruby in order to account for dynamic attributes. This is the incorrect way to handle dynamic data. The correct way would be to make subset data based on a parent data set. Example:
defaults: &defaults
host: localhost
production:
<<: *defaults
uri:
> Try storing a Proc in YAML. Yeah, that’s what I thought.
Procs aren’t stationary data. This is a moot point.
> All you need to do now is stop using YAML!
Great, now what if you want to share your stationary data with another language? Have you ever attempted to write “require ‘path/to/config.rb” in a Python script? I bet not, because it wouldn’t work.
The YAML library is in nearly *every* language, Ruby isn’t.
> Now, if we can only get Rails to drop the database.yml file, I think we’ll be all set.
Good luck with that, seriously. Because it’s never happening. Because easily machine readable stationary data specifications are *incredibly superior* to some block statement you just wrote, which will likely change fifty times over a given version. YAML will stay the same.
June 29th, 2011 at 4:33 am
I believe YAML as a config solutions in Rails is also kind of a “fool proof protection”. If all the configs would be stored in ruby, imagine what one can do in config files at some point: creating methods that generate helpers that generate config hashes that include links to files for dynamig config generation. Imagine the pain maintainer will have…
I’ve had a chance to work on python based projects and php based projects, and very vast amounts of those used config files written in project’s native language. Believe me, most of them was just a plain horror. I’m afraid, at some point such fate can hit rails too, and I wouldn’t like that,
Yeah, metaprogramming is good, but… let’s just keep it simple, shall we? All in all, if you need to put a proc in your config, then may be you’re doing something wrong.
June 29th, 2011 at 4:35 am
Your examples are not quite equivalent. Use:
SomeLibrary.config = {
‘foo’ => ‘bar’
}
Query: what if your app uses more than one configuration file?
Also, I think your article is somewhat misleading. A YAML file can get pretty large and still be very clean, Ruby, being a full-on programming language, has much more deliminator overhead. Try a few hash in hash layers and see how they fare.
Other advantages of YAML to consider:
* It can be read by most any program regardless of programming language.
* It can be more secure because it is static (when not using ERB).
* Support for YAML is distributed with Ruby.
YAML is pretty damn awesome too if you think about it, and if anything it needs more support from us so it can actually displace all this awful XML that’s used in “enterprisey” worlds.
BTW Don’t need a Proc:
foo-action:
puts “Yea that’s right”.
Ruby has eval
(Nothing against Configatron though. It’s look like a fine library. I just (heart) my YAML.)
June 29th, 2011 at 7:26 am
> Most everybody runs their YAML files through ERB so that they can make their YAML files more ‘Ruby-ish’.
>
Really? We mostly use the simple: YAML.load_file(‘/path/to/config.yml’). That’s sufficient for most purposes. When it needs to be more complex, agreed, just use Ruby to specify the configuration.
June 29th, 2011 at 7:51 am
YAML is excellent for MOST configs. If you have problems procs all over the place, use Ruby. if you don’t, don’t let a 2-liner require vs 1-liner require get you started preaching that YAML sycks for config. I would say Ruby sucks for config IMO; it was designed for expressing logic in first place. YAML is excellent example of “keep it simple”.
Why do Rubyists preach all this kind of best-practices that are really not best practices? I do wonder sometimes.
June 29th, 2011 at 11:10 am
I implemented a pure-Ruby database configuration DSL for Rails last year inspired by a similar post from Joe O’Brien (http://objo.com/2010/10/14/why-yml/). It was a thought experiment so I never submitted a patch or anything, but I did have it working. Maybe it’s time to reconsider? https://gist.github.com/628508#file_database.rb
June 29th, 2011 at 11:25 am
I prefer YAML-configuration for configuration the user (admin) may change through the web interface, because it’s easy to write back yaml-code into a file. For configurations which will not change at runtime of the app I prefer the ruby-way. Tho, I {blush}didn’t make this split consequently yet{/blush}.
June 29th, 2011 at 1:43 pm
This is amusing, but for most projects counterproductive.
The example provided grew 3x in overall size and 5x in the amount of punctuation necessary, for achieving the same thing. Not really an improvement.
The idea of a configuration file, usually, is to provide a *simple* means of configuring the program. When you are editing config file on a server in a terminal you don’t want any of “full power of ruby”.
If you are writing a program for users (as opposed to a ruby library for ruby developers) your users may not even know ruby syntax. Yaml on the other hand is easy to understand.
Now, providing a ruby configuration api for a ruby library is an entirely different story.
June 29th, 2011 at 9:13 pm
Two reasons why I’ve chosen YAML for configuration for my company SaaS CMS:
- It is programmatically modifiable
- It is not a programming language so any user can edit it without doing any harm
OTOH we also use application language (PHP, in our case) as configuration language on other simpler scenarios.
June 29th, 2011 at 9:48 pm
What about internationalization files, for example? It sounds like very large files, probably with several nested levels, in this case YAML seems more suitable. This is just an example where a config file written in ruby code could be a bit annoying, too many braces and too many => operators
July 5th, 2011 at 11:46 pm
I have to agree with most of the other commenters. I think configuration in Ruby is a poor way to implement human-readable configuration options. Not all configurations should have to be ported when implementation is changed, and sometimes a configuration is shared across implementations. Also, YAML is more concise, certainly less verbose than a Ruby-based config.
August 6th, 2011 at 11:58 am
Configatron without YAML
Pros
- That ugly hack with changing YAML engine causes serious problems under JRuby.
Cons
- Does the same job as Configuration gem which is much simpler. And Configuration gem does not pollute Ruby base classes with its own extensions.
August 17th, 2011 at 11:45 am
Your initial premise about having to type too much to include a yaml config file is negated by the fact that the point of yaml is to type less and understand more in the yaml file, not in the code you’re including the file in. And when you’re writing your library are you really going to be changing that yaml load function? probably not. but you might change your config file a few times.