Where should I put my config file, and how to load it?

[Ian Bridgeman]

Hello all!

I have a small app/set of libraries I'm developing at work called
Sweet. I'm distributing it internally as a ruby gem, which is working
nicely. However I rather foolishly put Sweet's yaml config file in its
config/ directory, so now every time the gem gets upgraded, it wipes
out the current settings. Oops! 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?

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.

Any assistance would be greatly appreciated!

- Ian

(Instances of the words 'config file' in this email: 4)

 

[Marnen Laibow-Koser]

Hello all!

I have a small app/set of libraries I'm developing at work called
Sweet. I'm distributing it internally as a ruby gem, which is working
nicely. However I rather foolishly put Sweet's yaml config file in its
config/ directory, so now every time the gem gets upgraded, it wipes
out the current settings. Oops! 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?

Only if your gem is meant as an executable application.

Or am I going
mad?

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.

Put the yaml in the Config object.

Any assistance would be greatly appreciated!

- Ian

(Instances of the words 'config file' in this email: 4)

Best,

 

[David Masover]

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.

Depending what the config file looks like, you may want to allow the global
one to be overridden by the local one -- that is, something to the effect of:

global_options.merge(local_options)

Also, I wouldn't insist on putting anything in /etc. If users want to create
/etc/sweetrc, go for it, but I'd say default back to something inside your
gem, so no installation other than 'gem install' is required.

Also, it's probably not an rc, since it's yaml. It's probably a .yaml or
conf. The 'rc' stands for 'run command', which implies it's an actual script
-- compare to, for example, irbrc.

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']

That makes sense, if you actually need that to be inside the class. You
probably also want it to be possible to override by specific instances of the
class, or by someone calling the class, but that might be overkill.

 

[Brian Candler]

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.

 

[Intransition]

Hello all!

I have a small app/set of libraries I'm developing at work called
Sweet. I'm distributing it internally as a ruby gem, which is working
nicely. However I rather foolishly put Sweet's yaml config file in its
config/ directory, so now every time the gem gets upgraded, it wipes
out the current settings. Oops! 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?

Please, don't use ~/.sweetrc. Be cool and kind and use XDG standard.

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
http://xdg.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 =3D Sweet::Config['data_directory']

Off the top of my head:

class Sweet::Config
DEFAULTS =3D {... }
def initialize
file =3D XDG.config_find('sweet/config.yaml')
data =3D file ? YAML.load(File.new(file)) : {}
@data =3D DEFAULTS.merge(data)
end
def self.global
@global ||=3D new
end
def self.[](key)
global[key.to_s]
end
end

 

[Ian Bridgeman]

Thanks for all the responses, guys, this has given me plenty to think about!

- Ian