configs's Introduction

Configs

Loads and manages config/*.yml files.

Searches through a few locations to find the right environment config:

config/$name/$env.yml
config/$name.yml (with $env key)
config/$name/default.yml
config/$name.yml (with 'default' key)

Installation

Add this line to your application's Gemfile:

gem 'configs'

And then execute:

$ bundle

Or install it yourself as:

$ gem install configs

Usage

If you have a config/foo.yml, then anywhere you need to read the file you can use Configs[:foo] as a hash.

Example:

# config/foo.yml
development:
  hello: world

# Elsewhere (even in a config/initializer)
Configs[:foo][:hello]
=> 'world'

You can include ERB in the YAML files:

# config/foo.yml
development:
  database_password: <%= ENV['DATABASE_PASSWORD'] %>

Contributing

Fork it
Create your feature branch (git checkout -b my-new-feature)
Commit your changes (git commit -am 'Added some feature')
Push to the branch (git push origin my-new-feature)
Create new Pull Request

License

Released under an MIT License

configs's People

Contributors

Stargazers

Watchers

configs's Issues

License missing from gemspec

Some companies will only use gems with a certain license.
The canonical and easy way to check is via the gemspec
via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

There is even a License Finder to help companies ensure all gems they use
meet their licensing needs. This tool depends on license information being available in the gemspec.
Including a license in your gemspec is a good practice, in any case.

If you need help choosing a license, github has created a license picker tool

How did I find you?

I'm using a script to collect stats on gems, originally looking for download data, but decided to collect licenses too,
and make issues for gemspecs not specifying a license as a public service :)
https://gist.github.com/bf4/5952053#file-license_issue-rb-L13 So far it's going pretty well.
I've written a blog post about it

Recommend Projects