Where should I put my config file, and how to load it?
in [Ruby]
|
From: Ian Bridgeman on 24 Nov 2009 11:33 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)
From: Marnen Laibow-Koser on 24 Nov 2009 12:25 Ian Bridgeman wrote: > 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, -- Marnen Laibow-Koser http://www.marnen.org marnen(a)marnen.org -- Posted via http://www.ruby-forum.com/.
From: David Masover on 24 Nov 2009 13:28 On Tuesday 24 November 2009 10:33:18 am 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. 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.
From: Brian Candler on 25 Nov 2009 05:11 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/.
From: Intransition on 25 Nov 2009 07:30
On Nov 24, 11:33 am, Ian Bridgeman <theadmi...(a)gmail.com> wrote: > 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 = Sweet::Config['data_directory'] Off the top of my head: class Sweet::Config DEFAULTS = {... } def initialize file = XDG.config_find('sweet/config.yaml') data = file ? YAML.load(File.new(file)) : {} @data = DEFAULTS.merge(data) end def self.global @global ||= new end def self.[](key) global[key.to_s] end end |