Friendly configuration wrapper. If you find yourself using things like:
AppConfig = YAML.load_file('config/app.yml')[environment].symbolize_keys
then you might like this.
Add this line to your application's Gemfile:
And then execute:
Or install it via RubyGems as:
$ gem install basic_config
# Loading config is simple settings = BasicConfig.load_file('config.yml') # It's a simple variable, you can create as many as you like. # You can use constants for convinience: AppConfig = BasicConfig.load_file('config/app.yml') DatabaseConfig = BasicConfig.load_file('config/database.yml') # Access your configuration with simple method calls settings.some_param # At any level of nesting settings.smtp.address # Hash access also works settings[:smtp][:address] # And you can check if particular key exists puts('Yes') if settings.include?(:smtp)
If your file has sections for different environments:
development: host: localhost port: 123 test: host: localhost port: 456
then you can load the right environment with
AppConfig = BasicConfig.load_env('config.yml', Rails.env)
Why should I use it instead of plain Hash variables?
It raises errors when you unintentionally read non-existent keys
If you are using a
secret_token = AppConfig[:something]
and for some reason your configuration does not have
:something in it (or you
make a typo) - you'll get a
nil. Worst case: this
nil will live inside your system compromising
or corrupting some data until you finally notice and track it down back to this line.
If you are using a
secret_token = AppConfig.something
NoMethodError in that particular line with the name of the key that
Note: There is also an
include? method which you can use to check if
particular key exist in your config -
Additionaly, for some keys it makes sense to get a
nil when they do not exist and for this
purpose there is a
 method which is delegated to underlying hash.
If your YAML is more than 1 level deep then simple
symbolize_keys is not going to be enough:
With BasicConfig above would look like this:
Easier to test
You can stub out any config variable just like a normal method in your tests.
The only thing that I can think of is be aware that you can not use Ruby Object
method names for your configuration variable names (
display, etc, you can see the full list with