From: Brian Candler <b.candler@...>
Date: 2009-11-25T19:11:24+09:00
Subject: Re: Where should I put my config file, and how to load it?

Ian Bridgeman wrote:
> My plan to fix this problem is to
> store the config file at ~/.sweetrc, with a global config file at
> /etc/sweetrc to fall back to if the home directory one isn't
> available. Does this sound like a sensible solution? Or am I going
> mad?

If your config is simple, you could just load the hard-coded defaults 
into a hash, load in the user's config from .sweetrc into another hash, 
and then use merge() so that the final config consists of the defaults 
with the user's overrides.

If it's more complex or you want to provide the user with a config 
template to edit, you could check if ~/.sweetrc exists, and if it 
doesn't then copy config/sweetrc.default to ~/.sweetrc

However the latter approach may store up problems for the future. If 
your config file format changes, or you add new mandatory parameters, 
then users may end up running the new code with the old config, and 
you'll have to provide a migration tool to merge their old settings with 
the new ones.

So what you really want to do is to identify settings which are new 
(merge them in), and those which are obsolete (and remove them). The 
solution used by courier-mta is called sysconftool, and it marks up the 
config with special comments to identify the sections.
http://www.courier-mta.org/sysconftool/

There's a ruby implementation that I wrote ages ago:
http://rconftool.rubyforge.org/

> The second (and more ruby-ish) question I have is: How can I make sure
> all my classes have access to the contents of the config file? My
> classes all reside within the 'Sweet' module, and ideally I would like
> to be able to do something along the lines of
> 
> @data_directory = Sweet::Config['data_directory']
> 
> in the initialisation method of any of my classes. Previously all of
> the code was pretty much in one class, so that class just had a method
> to load the yaml, but I'm doing a pretty major refactoring for Sweet
> v2.

I think that's fine. You can put the config-reading code into 
sweet/config.rb, so that the clients just need to do
  require 'sweet/config'
to ensure the Sweet::Config object is available.
-- 
Posted via http://www.ruby-forum.com/.