View on
MetaCPAN is shutting down
For details read Perl NOC. After June 25th this page will redirect to
Karim A. Nassar > Activator-0.91 > Activator::Options



Annotate this POD

View/Report Bugs


THIS MODULE DEPRECATED. USE Activator::Config instead.

Activator::Options - process options for a script combining command line, environment variables, and configuration files.


  use Activator::Options;

  my $opts = Activator::Options->get_opts( \@ARGV);  # default realm
  my $opts = Activator::Options->get_opts( \@ARGV, $otherrealm);

  #### Get a hashref of command line arguments, and an arrayref of barewords
  my ( $argv, $barewords ) = Activator::Options->get_args( \@ARGV );


This module allows a script to obtain options from command line, envirnoment variables, and YAML configuration files.

Prcedence Heirarchy

The precedence heirarchy from highest to lowest is:

Configuration File Heirarchy

In order to facilite the varied ways in which software is developed, deployed, and used, the following heirarchy lists the configuration file heirarchy suported from highest to lowest:

  $ENV{USER}.yml - user specific settings
  <realm>.yml    - realm specific settings and defaults
  <project>.yml  - project specific settings and defaults
  org.yml        - top level organization settings and defaults

It is up to the script using this module to define what project is, and up to the project to define what realms exist, which all could come from any of the command line options, environment variables or configuration files. All of the above files are optional and will be ignored if they don't exist, however at least one configuration file must exist for the get_opts() function.

Configuration File Search Path

TODO: This functionality is not implemented yet. Currently, only ~/.activator.d/<project> is supported

The search path for configuration YAML files is listed below. The first conf file for each level appearing in the following directories will be utilized:

  --conf_path=<paths_to_conf_dir>        # colon separated list
  --conf_files=<conf_files>              # comma separated list
  /etc/activator.d/                      # useful for org.yml

It is up to the script to define what project is by insuring that $ENV{ACT_OPT_project} is set. This module will throw Activator::Exception::Option it is not set by you or passed in as a command line argument, so you could force the user to use the --project option if you like.


This module supports the concept of realms to allow multiple similar configurations to override only the esential keys to "git 'er done".

Configuration Logic Summary


This module allows long or short options using '-' or '--' notation, allows barewords in any order, and recognizes the arguments terminator '--'. Also supported are multiple flag arguments:

  #### turn on super verbosity. sets $opts->{v} = 2 -v -v

You can specify configured options at the command line for override:

  #### override the configuration file setting for 'foo' --foo=bar

Command line overrides only apply to keys that exist in a configuration file and any unrecognized options are ignored. @ARGV is modified to remove recognized options, leaving barewords and unrecognized options in the order they were specified. This module has no support for argument validation, and your script must handle unrecognizd options and behave appropriately. There are numerous modules on CPAN that can help you do that (Getopt::Long for example). If you do use another options module, make sure you call get_opts() BEFORE you call their processor, so that @ARGV will be in an appropriate state.

Also, while YAML configuration (and this module) support deep structures for options, you can only override top level keys that are scalars using command line arguments and/or environment variables.

Special Arguments

There are a few special command line arguments that do not require YAML existence:

 --skip_env        : ignore environment variables
 --project=<>      : use this value for <project> in config file search path.
 --project_home=<> : useful for when utilizing <project_home>/.<project> config dir
 --realm=<>        : use <realm>.yml in config file processing and consider all
                     command line arguments to be in this realm

TODO: these are not implemented yet

Also supported are these variables which can be listed as many times as necessary:

 --conf_file=<> : include <> file for inclusion
 --conf_path=<> : include <> path when looking for config files


Environment variables can be used to override any top level YAML configuration key which is a scalar. The expected format is ACT_OPT_[key]. Note that YAML is case sensitive, so the environment variables must match. Be especially wary of command shell senstive characters in your YAML keys.

If you wish to override a key for only a particular realm, you can insert the realm into the env variable wrapped by double underscores:

 ACT_OPT_foo       - set 'foo' for default realm
 ACT_OPT__bar__foo - set 'foo' only for 'bar' realm

The special command line arguments listed in the COMMAND LINE ARGUMENTS section also have corresponding environment variables with minor differences in use:

 ACT_OPT_skip_env     : set to 1 to skip, or 0 (or don't set it at all) to
                        not skip
 ACT_OPT_project      : same as command line argument
 ACT_OPT_project_home : same as command line argument
 ACT_OPT_realm        : same as command line argument
 ACT_OPT_conf_file    : comma separated list of files
 ACT_OPT_conf_path    : colon separated list of directories



This module suports realms such that when passing a realm to get_opts() (or via the --realm command line argument), values for the realm take precedence over the default realm's values. For example, given YAML:

    key1: value1
    key1: value2

Activator::Options->get_opts( \@ARGV ) would return:

$opts = { key1 => value1 }

and Activator::Options->get_opts( \@ARGV, 'realm' ) would return:

$opts = { key1 => value2 }


Sometimes it is desireable to force a value to override the organiztaion/project/realm value when many config files are merged to create the $opts hash. The special realm overrides can be utilzed in these cases, and will stomp any values that come from YAML configurations. E.g.:

    name: David Davidson from Deluth, Delaware
    name: Sally Samuelson from Showls, South Carolina
    name: Ollie Oliver from Olive Branch, Oklahoma
      name: Ron Johnson from Ronson, Wisconson
      name: Johnny Jammer, the Rhode Island Hammer

Would produce the following $opts:

 $opts = {
    default => {
       name => 'Ron Johnson from Ronson, Wisconson',
    some_realm => {
       name => 'Johnny Jammer, the Rhode Island Hammer',
    other_realm => {
      name => 'Ron Johnson from Ronson, Wisconson',

Variable Substitution


Substitution occurs as the last step of processing. Every value for every key (including values within lists ) are visited. Values for any key can optionally contain a reference to another key by using ${} notation. Use the indirect operator '->' to reference deeply nested values. For example:

    key1: value1
    key2: value2
    foo: bar
    key2: ${key1}
    key3: ${realm1->foo}/${key2}         # value == 'bar/value2'
    key4: ${realm1->foo}/${realm2->key2} # value == 'bar/value1'

Note that you must fully qualify any deeply nested references.



Constructor: implements singleton. Not very useful. Use get_opts().



  Activator::Options->get_opts( \@ARGV );         # default realm
  Activator::Options->get_opts( \@ARGV, $realm );

Strip recognized options from @ARGV and return the configuration hash $opts for $realm based on @ARGV. $realm is optional (default is 'default'), and if not specified either the command line argument (--realm) or environment variable (ACT_OPT_<realm> unless ACT_OPT_skip_env is set) will be used. Not specifying a realm via one of these mechanisms is a fatal error.


  #### get options for default realm
  my $opts = Activator::Options->get_opts( \@ARGV );

  #### get options for 'some' realm
  my $opts = Activator::Options->get_opts( \@ARGV, 'some' );

See get_args() for a description of the way command line arguments are processed.


Usage: Activator::Options->get_args( $argv_raw )

Takes a reference to a list of command line arguments (usually \@ARGV) and returns a hash. $argv_raw is not changed.


  @ARGV                | Value returned
  --arg                | $argv = { arg => 1 }
  --arg --arg          | $argv = { arg => 2 }
  --arg=val            | $argv = { arg => 'val' }
  --arg=val --arg=val2 | $argv = { arg => [ 'val', 'val2' ] }
  --arg="val val"      | $argv = { arg => 'val val' }

Returns array: ( $args_hashref, $barewords_arrayref )

Throws Activator::Exception::Option when arg is invalid (which at this time is only when a barewod arg of '=' is detected).


Since this module is part of Activator, you can set your Activator::Log level to DEBUG to see how your $opts are generated.

 #### TODO: in the future, there needs to be a 'lint' hash within the
 #### realm that says where every variable came from.


This section gives some examples of how to utilze this module. Each section below (cleverly) assumes we are writing a Cookbook application that can fetch recipies from a database.

 #### TODO: these examples use currently unimplemented features. FIX IT!

End User

Use Case: A user has a CPAN module that provides to lookup recipies from a database. The project installs these files:


org.yml has the following data:

    db_name:   cookbook
    db_user:   chef
    db_passwd: southpark

The user can run the script as such:

  #### list recipes matching beans in the organization's public db
  #### using the public account lookup beans

  #### lookup beans in user's db --db_name=my_db  \
              --db_user=cookie \
              --db_passwd=cheflater  lookup beans

  #### user creates $HOME/$USER.yml --conf_file=$HOME/$USER.yaml lookup beans

  #### user creates $HOME/.cookbook.d lookup beans

Simple Development

Use Case: developer is working on Project directory looks like:


With these configurations:

    db_name:   cookbook
    db_user:   chef
    db_passwd: southpark

    db_name:   $USER
    db_user:   $USER
    db_passwd: passwd
    db_name:   staging
    db_user:   test
    db_passwd: test

  #### when developing, call the script like this to lookup bean
  #### recipies from developers personal db
  cd $HOME/src/Cookbook
  bin/ lookup beans

  #### To demo the project to someone else, developer creates a demo
  #### account, which has the environment variable ACT_OPT_realm set
  #### to 'staging'. demo user then uses the script as if it were
  #### installed, but connects to the staging database: lookup beans

  #### if the developer wants to see what the demo user sees:
  cd $HOME/src/Cookbook
  bin/ --realm=staging lookup beans

TODO: complex development ^

Someday, we'll have a really neat example of all the goodness this module is capable of.




Karim A. Nassar


Copyright (c) 2007 Karim A. Nassar <>

You may distribute under the terms of either the GNU General Public License or the Artistic License, as specified in the Perl README file.

syntax highlighting: