Project

dry-config

0.01
No commit activity in last 3 years
No release in over 3 years
Simple base class for DRY environment based configurations.
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
 Dependencies

Development

>= 0
>= 0

Runtime

 Project Readme

dry-config

Gem Version Build Status Code Climate

Simple base class for DRY inheritable configurations that can be loaded from multiple overriding yml files.

Sample uses include environment based e.g. development, test, production and multi-domain white label configurations.

A programmatic seed configuration may be specified, as well as the ability to load one to many overriding configuration files.

Results may be re-written to an output file, useful for compiling static files for other processes such as docker-compose.yml.

The elastic-beanstalk gem is a real world example that utilized Dry::Config::Base.

Installation

Add this line to your application's Gemfile:

gem 'dry-config'

And then execute:

$ bundle

Or install it yourself as:

$ gem install dry-config

Example 1: environment inheritance

The following example shows a single file where environments will override base level settings. dry-config is useful for simple, to multi-file, multi-environmet settings.

Step 1. Write a config class

Note this sample uses the Singleton pattern, which is useful but not required.

require 'singleton'
require 'dry/config'

class AcmeConfig < Dry::Config::Base
    
    # (optional) make this the only instance 
    include Singleton
    
    def initialize(options = {})
      options = {
          # seed the sensible defaults here (overridable)
          default_configuration: {
              environment: nil,
              strategy: :blue_green,
              package: {
                  verbose: false
              },
              options: {}
          }}.merge(options)

      super(options)
    end
end

Step 2. Write a yml config file

# sample config demonstrating multi-environment override
---
app: acme
title: Acme Holdings, LLC
#---
options:
  aws:elasticbeanstalk:application:environment:
    RAILS_ENV: foobar

  aws:autoscaling:launchconfiguration:
    InstanceType: foo

#---
development:
  strategy: inplace-update
  package:
    verbose: true
  options:
    aws:autoscaling:launchconfiguration:
      InstanceType: t1.micro
    aws:elasticbeanstalk:application:environment:
      RAILS_ENV: development

#---
production:
  options:
    aws:autoscaling:launchconfiguration:
      InstanceType: t1.large
    aws:elasticbeanstalk:application:environment:
      RAILS_ENV: production    

Step 3. Load your config

Note that multiple files can be loaded and overriden. A nil environment is also possible.

AcmeConfig.instance.load!(:production, 'path_to/acme.yml')

Step 4. Use the values

Note that all keys are symbolized upon loading.

config = Acme.config.instance
config.load!(:production, 'path_to/acme.yml')

config.app          # acme
config.title        # Acme Holdings, LLC    
config.strategy     # :blue_green,
config.options[:'aws:autoscaling:launchconfiguration'][:InstanceType] # t1.large

Example 2: Multi-file White Label sample

    class WhiteLabelConfig < Dry::Config::Base
    end

    config = WhiteLabelConfig.new
    config.load!(nil, 'base.yml', 'acme.com.yml', 'scheduling.acme.com.yml')

ENV Interpolation/substitution/expansion

ENV variable substitution is supported and enabled by default. It may be disabled by initializing with {interpolation: false}.

The following formats are acceptable:

interpolations:
  - ~/foo
  - $HOME/foo
  - ${HOME}/foo
  - #{HOME}/foo
  # mixed example
  - ~/docker/mysql/${PROJECT_NAME}-${BUILD}:/var/lib/mysql:rw

Options

The default configuration is provided below, override any of these values on construction:

{
    env: ENV,                  # default to ENV for interpolation
    interpolation: true,       # interpolate contents on read with env (above defaults to the current process's ENV)
    symbolize: true,           # provide symbol based key access for everything i.e. access :development instead of 'development' as a rule
    unsymbolize_to_yaml: true, # on to_yaml or write_yaml_file unsymbolize keys (several external tools do not do well with symbolized keys i.e. write `development:` instead of `:development:`
    default_configuration: {}, # seed configuration (file contents overlay this)
    prune: 
        [:development, :test, :staging, :production] # used for pruning final configuration (optional - nice to have cleanup)
}

Contributing

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request