Enables Settings.get(‘nested.key.name’) for dynamic access

Initializes a new settings object. You can initialize an object in any of the following ways:

  Settings.new(:application) # will look for config/application.yml
  Settings.new("application.yaml") # will look for application.yaml
  Settings.new("/var/configs/application.yml") # will look for /var/configs/application.yml
  Settings.new(:config1 => 1, :config2 => 2)

Basically if you pass a symbol it will look for that file in the configs directory of your rails app, if you are using this in rails. If you pass a string it should be an absolute path to your settings file. Then you can pass a hash, and it just allows you to access the hash via methods.

Use instance_eval/class_eval because they‘re actually more efficient than define_method{} stackoverflow.com/questions/185947/ruby-definemethod-vs-def bmorearty.wordpress.com/2009/01/09/fun-with-rubys-instance_eval-and-class_eval/

This handles naming collisions with Sinatra/Vlad/Capistrano. Since these use a set() helper that defines methods in Object, ANY method_missing ANYWHERE picks up the Vlad/Sinatra settings! So settings.deploy_to title actually calls Object.deploy_to (from set :deploy_to, "host"), rather than the app_yml[‘deploy_to’] hash. Jeezus.

Called for dynamically-defined keys, and also the first key deferenced at the top-level, if load! is not used. Otherwise, create_accessors! (called by new) will have created actual methods for each key.

Returns an instance of a Hash object