escort 0.2.1 → 0.3.0

checksums.yaml

@@ -1,15 +1,15 @@
 ---
 !binary "U0hBMQ==":
   metadata.gz: !binary |-
-    N2Q0MmJiODEzODNjNWI0NmM3Mzc0ZGFmMGQyYTU5NzFkZWU3NmZjYw==
+    MzQ3YWNjMzdhYWVmMjJiNThhYmFkNDlmYTdhZjRiOTk1MTE5MjU0OA==
   data.tar.gz: !binary |-
-    YjM4NmE2YmVjOTdkOTg4MDY1MWFmZGRmZGM5NzdiYWIwN2M3NmE2ZQ==
+    MDA2MDVmNGQ5M2I2ODRlNGUzODU5YzgzYjI1ZTY3NjU2YzRjMmNiMg==
 !binary "U0hBNTEy":
   metadata.gz: !binary |-
-    ZTYxZWFiZmRmNzhlZjFhMjMyNTcxNzU3MGEzM2U4ZWYxOWZiOGJkOGMxNTli
-    N2Q0Yjk0ZGVlMmE5OThhOWQwMDU0YmQ2YjlmMjZlMjhlMWNmYjhlMDQ4NGJh
-    ZTVlYWJiMDZiMzJjYWMzMGNiNWQ0ZTZlYjFhYjg3Yjc4OTQ5M2U=
+    ZjBiNWM4N2MyMDQ3NDI2ZmQyZjI4NjBmZjg3YmZhZTRjNGU5ZDFlNjljYzYw
+    Y2Q0MThjMDQyYTg5YjAzZWE3ZDQ2NGFhZWIwZDE0MjU2MTZiZTk5MDdmZGVl
+    MWVmMTUzMTYzODc5NzcxYmEyZmE5MGI4NmNlNjI3MThkMWEyMDI=
   data.tar.gz: !binary |-
-    MDJlNGMwMWM1NTBkYzI3ZTI4MWM0NThhMTEzMDkyNThkZTFmNDEyMTgxYjA0
-    NDFkNzA3MjQ4MDU2NmM1ZmQ0ZjQxNDU3MTJhNjFhZmI2NjAwOGVmYjAzZTBm
-    ODYzNjVkMDM2NTM2NGJiY2I2NTlhYjRkMTAzMDA3OGM0ZDdhZTc=
+    ODkwMzNlN2Q0NTMwOGY2ZGQzYTA3YjA3ZTNiMjdkYTgzMjBmYmI1ZTVjNDQy
+    ZTM0ZGU2ZGZjNmVhYjhiMjdmZTVjY2NiNGY2ZGRmNmUzMTcyNmViMzNmYjQ4
+    NzQzN2MxMjlhOGFiN2UxZGE2ODc2MWZmY2IxODAzNjFkM2ViMmQ=

data/.irbrc

@@ -1 +1,3 @@
+$:.unshift File.expand_path(File.join(File.dirname(__FILE__), 'lib'))
+
 require './lib/escort'

data/.travis.yml

@@ -4,5 +4,5 @@ rvm:
   - "1.9.3"
   - "2.0.0"
   - jruby-19mode # JRuby in 1.9 mode
-  - rbx-19mode
+  #- rbx-19mode
 script: bundle exec rspec spec

data/README.md

@@ -213,6 +213,22 @@ This will execute fine, but if we do:
 
 The app will prompt the user to enter an argument. Pressing `Enter` will allow to enter more arguments. Like with many command-line apps you will need to press `Ctrl-D` to jump out of the prompt and allow the app to execute.
 
+There is one extra thing to note. If you're writing a command suite (see below for explanation). The `requires_arguments` setting will be inherited by all the sub-commands. You can however easily override the setting for any sub-command and this overridden value will be inherited by all the sub-commands of that command.
+
+```ruby
+...
+  app.command :start do |command|
+    command.requires_arguments false
+
+    command.action do |options, arguments|
+      MyApp::ExampleCommand.new(options, arguments).execute
+    end
+  end
+...
+```
+
+This way different commands in your app can pick and choose whether or not they want to require arguments or make them optional.
+
 
 ### Better Help Text
 
@@ -409,12 +425,265 @@ As you can see you may define multiple validation rules for the same option with
 
 
 ### Configuration File
-TODO
 
-### Commands
+Sometime you have a whole bunch of command line options you need to pass in to your app, but the value of these options hardly ever changes. It's a bit of a drag to have supply these on the command-line every time. This is why we have config file support. You may indicate that your app has a config file like so:
+
+```ruby
+#!/usr/bin/env ruby
+
+require 'escort'
+require 'my_app'
+
+Escort::App.create do |app|
+  app.config_file ".my_apprc", :autocreate => true
+
+  app.options do |opts|
+    opts.opt :option1, "Option1", :short => '-o', :long => '--option1', :type => :string, :default => "option 1"
+  end
+
+  app.action do |options, arguments|
+    MyApp::ExampleCommand.new(options, arguments).execute
+  end
+end
+```
+
+Essentially we give the config file a name and optionally set the config file to be autocreatable. When the config file is autocreatable, the first time you run the command-line app, a config file with the name your specified will be created in the default location (which is your home directory). The config file format is JSON, and it is structured in a specific way to support infinitely nesting sub commands. The config file for an app like the one above, might look like this:
+
+```
+{
+  "global": {
+    "options": {
+      "option1": "option 1",
+      "config": null,
+      "verbosity": "WARN",
+      "error_output_format": "basic"
+    },
+    "commands": {
+      "escort": {
+        "options": {
+          "create_config": null,
+          "create_default_config": null,
+          "update_config": null,
+          "update_default_config": null
+        },
+        "commands": {
+        }
+      }
+    }
+  },
+  "user": {
+  }
+}
+```
+
+All the options you can supply to your app will be present in the config file as well as all the commands and all their options etc (you also get a bunch of options and a single command that get automatically added by escort for your convenience, these will be explained below). You can go and modify the values for all your options in the config file. The config file values, take precedence over the default values that you specified for the options (if any), but if you supply an option value on the command-line, this will still take precedence over the option value you define in the config file. This way you can provide sensible defaults and still override when necessary.
+
+Whenever you define an app to have a config file, escort will add some utility options and commands for you to make working with config files easier. Firstly, you will get a global `config` option. This can be used to make your app take a specific config file instead of the default one, this config file will only be valid for the single execution of your command-line app e.g.:
+
+```
+./app.rb --config='/var/opt/.blahrc' -o yadda
+```
+
+You also get a utility command for working with config files - the `escort` command. This command has 4 options:
+
+* `--create-config` - this can be used to create a config file in a specified location
+* `--create-default-config` - this can be used to create a config file in the default location (home directory) if one doesn't already exit
+* `--update-config` - this can be used to update a specific config file (mainly useful during development), if you've added new options/commands using this option will allow your config file to reflect this (it will not blow away any of the values you have set for your options)
+* `--update-default-config` - same as above but will just work with the default config file if it is present (if not, it will create a default config file)
+
+These utility options can be very useful as the nested format of the config file can become confusing if you have to update it by hand with new options and commands while you're developing your apps.
+
+It is also worth knowing that Escort is quite clever when it comes to working out which config file to use for a particular run of the command-line app. It will not just use the config file in your home directory, but will instead attempt to find a config file closer in the directory hierarchy to the location of the command-line script. The strategy is as follows:
+
+* look for a config file in the directory where the command-line script itself lives, if found use that one
+* otherwise look for a config file in the current working directory and use that one
+* if still not found, go down one level of the directory tree from the current working directory and look for a config file there
+* keep going down the directory tree until the home directory is reached, if no config file was found, then no config file exists
+* in which case either create the config file in home directory (if autocreatable) or continue without config file
+
+As you can see the config file support is quite extensive and can take your command-line apps to the next level in terms of useability and utility.
+
+
+### Command Suites
+
+You're not just limited to options for your command-line apps. Escort allows you to turn your command-line apps into command-line suites, with command support. Let's say you want a command-line app to control a process of some sort. Your process is `app.rb`. What you want to be able to do is the following:
+
+```
+./app.rb start
+./app.rb stop
+./app.rb restart
+```
+
+You also want to be able to provide options both to the main process itself as well as to the various commands, e.g.:
+
+```
+./app.rb -e production start --reload
+```
+
+Escort makes this easy:
+
+```ruby
+#!/usr/bin/env ruby
+
+require 'escort'
+require 'my_app'
+
+Escort::App.create do |app|
+  app.config_file ".my_apprc", :autocreate => true
+
+  app.options do |opts|
+    opts.opt :environment, "Environment", :short => '-e', :long => '--environment', :type => :string, :default => "development"
+  end
+
+  app.command :start do |command|
+    command.summary "Start process"
+    command.description "Start process"
+
+    command.options do |opts|
+      opts.opt :reload, "Reload", :short => '-r', :long => '--reload', :type => :flag
+    end
+
+    command.action do |options, arguments|
+      MyApp::ExampleCommand.new(options, arguments).execute
+    end
+  end
+
+  app.command :stop do |command|
+    command.summary "Stop process"
+    command.description "Stop process"
+
+    command.action do |options, arguments|
+      MyApp::ExampleCommand.new(options, arguments).execute
+    end
+  end
+
+  app.command :restart do |command|
+    command.summary "Restart process"
+    command.description "Restart process"
+
+    command.action do |options, arguments|
+      MyApp::ExampleCommand.new(options, arguments).execute
+    end
+  end
+end
+```
+
+Of course you would probably use a different `ActionCommand` class to implement each of your defined commands (more on `ActionCommands` below).
+
+
+### Command Suites Sub-Commands
+
+Of course if one level of commands is good it is only logical that multiple levels of commands is even better. Luckily Escort supports infinitely nesting sub-commands so you can create command-line suites which are truly extensive. Let's say you're writing a command-line utility for your framework, you've named your framework 'Rails' (cause surely that's not taken :P) and your utility is `rails`. You want your utility to be used for generating migrations as well as controllers, something like:
+
+```
+rails generate migration
+rails g controller
+```
+
+Of course you want to be able to supply a set of options to each of the sub-commands when necessary:
+
+```
+rails -e development generate migration --sequel
+```
+
+As we've come to expect, this is very easy:
+
+```ruby
+#!/usr/bin/env ruby
+
+require 'escort'
+require 'my_app'
+
+Escort::App.create do |app|
+  app.config_file ".my_apprc", :autocreate => false
+
+  app.options do |opts|
+    opts.opt :environment, "Environment", :short => '-e', :long => '--environment', :type => :string, :default => "development"
+  end
+
+  app.command :generate, :aliases => [:g] do |command|
+    command.command :migration do |command|
+      app.options do |opts|
+        opts.opt :sequel, "Sequel", :short => '-s', :long => '--sequel', :type => :flag
+      end
+
+      command.action do |options, arguments|
+        MyApp::ExampleCommand.new(options, arguments).execute
+      end
+    end
+
+    command.command :controller do |command|
+      command.action do |options, arguments|
+        MyApp::ExampleCommand.new(options, arguments).execute
+      end
+    end
+  end
+end
+```
+
+Of course, you can flesh it out by providing a summary and description for the commands, specifying if arguments are required, conflicts, dependencies etc (this will be reflected in the help text). Just about everything you can do at the global level for apps without sub-commands, you can do at the command level (the only things you currently can't specify at the command level are 'version' and 'config_file', these are global only).
+
+
+### Implementing the Actions
+
+So far we've seen a lot of examples of how to add various command-line UI features, but what about implementing the actual functionality.
+
+If your functionality is a one liner, you can, of course, just dump it into the action block, but we're trying to keep a clean separation between our UI logic and the actual functionality we are trying to implement. We do this by writing `ActionCommand` classes.
+
+In all the previous examples you've seen the following:
+
+```ruby
+...
+
+  app.action do |options, arguments|
+    MyApp::ExampleCommand.new(options, arguments).execute
+  end
+
+...
+```
+
+The `ExampleCommand` is an `ActionCommand` and is implemented in a separate class. In the above examples we would `require 'my_app'` with the assumption that it requires the file where `ExampleCommand` is imlpemented. You could of course just require the file with the implementation directly.
+
+A command might look like this:
+
+```ruby
+module Escort
+  class ExampleCommand < ::Escort::ActionCommand::Base
+    def execute
+      Escort::Logger.output.puts "Command: #{command_name}"
+      Escort::Logger.output.puts "Options: #{options}"
+      Escort::Logger.output.puts "Command options: #{command_options}"
+      Escort::Logger.output.puts "Arguments: #{arguments}"
+      if config
+        Escort::Logger.output.puts "User config: #{config}"
+      end
+    end
+  end
+end
+```
+
+As you can see all you need to do is inherit from `::Escort::ActionCommand::Base` and implement the execute method. Inheriting from `Base` gives you access to a bunch of useful methods:
+
+* `command_name` - the name of the command that is being executed (or :global if it is the main action)
+* `command_options` - the options for this command
+* `parent_options` - the options for the parent command (if any)
+* `global_options` - the global app options
+* `config` - a hash of the user defined portion of the configuration file
+* `options` - the raw options hash
+* `arguments` - a list of arguments passed to the app
+
+These should give you hand in implementing the functionality you need, but most importantly it allows us to keep our actual command-line UI definition clean and separate the useful logic into what is/are essentially pure ruby classes.
+
+## Examples
+
+There is an examples directory where you can have a play with a whole bunch of little 'Escort' apps, from a very basic one with no options to more complex nested command suites with all the trimmings. Most of them call the `ExampleCommand` which lives in `examples/commands`. Have a read/play to learn, or just copy/paste bits straight into your apps.
+
+## More In-Depth
+
 TODO
 
-### Sub-Commands
+## Command-Line Tools Built With Escort
+
 TODO
 
 ## Alternatives

data/TODO.md

@@ -1,110 +1,85 @@
 ROADMAP
 
-v0.2.0
-- up the version to 0.2.0
+v0.3.0
 - tag and release
 
 
-- test conflicts for non-exstant options (integration) DONE
-- test all the new help stuff on option, for conflicts, dependencies, validations DONE
-- fix up readme for conflicts block    DONE
-- rework validations to be part of the options block rather than in their own block  DONE
-- fix example, fix tests, fix readme DONE
-- need to rework conflicts as currently not really very good   DONE
-- add dependencies to help text  DONE
-- add conflicts to help text     DONE
-- add validation texts to help text so that people can see what kind of values are valid  DONE
-- make sure we check conflicts for non-existant options   DONE
-- refactor the formatting code some more DONE
-- pull some formatting code into separate classes DONE
-- test some of the utility formatting code DONE
-- fix up help text so that if arguments are mandatory they are shown as mandatory not optional DONE
-- basic example with validations       DONE
-- integration test for validations     DONE
-- readme for validations               DONE
-- test the shell command executor, and the terminal class for width command DONE
-- improve the readme to explain
-  - a basic app with no options                                 DONE
-  - a basic app with options                                    DONE
-    - supplying multiple of the same parameter using multi      DONE
-  - a basic app with require arguments                          DONE
-  - a basic app specifying version, description and summary     DONE
-  - test the readme for flags to make sure it works as expected DONE
-  - a basic app with dependant options (mention that a deadlock situation can occur if you're not careful)  DONE
-- example for conflicting options                            DONE
-- integration test for conflicting options                   DONE
-- readme for conflicting options                             DONE
-- for print stacktrace, change it to print in INFO mode so that stacktrace not printed by default DONE
-- BUG when a script requires arguments and user doesn't supply any escort treats this as an internal error and asks you to report it, this shouldn't be the case DONE
-- depends_on support
-  - option depends on flag                                                                      DONE
-  - flag depends on another flag                                                                DONE
-  - one option depends on another (the other must be not false not nil and not empty)           DONE
-  - one option depends on specific value of another (the other must be of a specific values)    DONE
-  - one option depends on several others (where are must be not false not nil and not empty)    DONE
-  - one option depends on several others where some must have a specific value (some options have specific value, others are not false not nil and not empty)  DONE
-  - error if option for which dependecy is being defined does not exist                         DONE
-  - error if depends on non-existant option                                                     DONE
-  - error if depends on itself                                                                  DONE
-  - error if dependency not satisfied                                                           DONE
-  - error if missing on condition when specifying dependency                                    DONE
-  - refactor the options dsl class dependency code                                              DONE
-  - refactor the option_dependency_validator class to be nicer                                          DONE
-  - integration test all the permutations of dependency specification with error and success cases etc  DONE
-  - create a shortcut for dependency specification on the opt method options hash itself                DONE
-  - fix up example for basic app with dependencies for options                                          DONE
+- up the version to 0.3.0 DONE
+- test the base command for actions well DONE
+- BUG parent_options when parent of command is global context doesn't seem to work??? DONE
+- integration test for commands   DONE
+- integration test for sub-commands DONE
+- readme a basic app with config file, integration test (don't worry about explaining all the helper stuff that gets created) DONE
+- test the configuration loader DONE
+- test the descend to home locator DONE
+- test the configuration merge tool DONE
+- test the configuration generator DONE
+- test all the locators (descend, specfic dir, current script dir, chaining) DONE
+- we should always be using the chaining locator, with more or less sub locators depending on setup DONE
+- create other locators (dir of currently executing script locator, i.e. not the working directory, specified dir locator) DONE
+- create a chaining locator so we can put all our locators together  DONE
+- test the configuration reader DONE
+- test the configuration writer  DONE
+- a basic app example with all the trimmings DONE
+- app with config file example     DONE
+- readme implementing and action for a basic app DONE
+- rejig for betterness the validations help outputs DONE
+- test the string grid      DONE
+- start using the new stream output formatter   DONE
+- refactor terminal formatter and test it     DONE
+- finish testing the output formatter        DONE
+- get rid of shell command executor new shell stuff (doesn't work in Jruby and not really needed anyway)  DONE
+- extract all the dsl command stuff into a helper module so that global and command can be handled by the same code DONE
 
 v0.4.0
-- readme a basic app with config file (don't worry about explaining all the helper stuff that gets created)
-- readme implementing and action for a basic app
-- refactor terminal formatter and test it
-- refactor borderless table and test it
-- BUG parent_options when parent of command is global context doesn't seem to work???
-- test the base command for actions well
+- test all the config file helper stuff
+- a few more tests (setup accessor, all the dsl classes)
 - fix ppjson so that dependency suport feature is actually used
-- readme a command app with options, validations, description, summary, require arguments and config file, integration tests for commands, example
-- readme a sub command app with options, validations, description, summary, require arguments and config file
-- extract all the dsl command stuff into a helper module so that global and command can be handled by the same code
-- delete the stuff from the attic once it is no longer needed
-- get rid of shell command executor new shell stuff (doesn't work in Jruby and not really needed anyway)
 - up the version to 0.4.0
 - tag and release
 
 
+- delete the stuff from the attic once it is no longer needed DONE
+- readme a sub command app with options, validations, description, summary, require arguments and config file, integration tests, example DONE
+- readme for requires arguments overriding and inheritance DONE
+- readme explain all the helper stuff that automatically gets created with config file support DONE
+
+
 v1.0.0
-- perhaps rework actions with passing a class and having it being auto called
-- implement servants for dealing with clumps of functionality, and action commands have access to all servants that were executed before them
-- a few more tests (setup accessor, all the dsl classes)
-- for borderless table, should be able to create another borderless table within a cell of an existing table
 - have a think about how to make the integration tests a bit more robust, so that failures don't get swallowed (test for specific exit codes instead of non-zero exit code), fix the existing integration tests
-- in trollop when errors are raised they should be wrapped as escort errors and propagate rather than being caught by trollop itself
 - a few more integration tests (test that basic app automatically gets help and other automatic options)
+- clean up all the extraneous branches
 - up the version to 1.0.0
 - tag and release
 - get the blog updated with a new theme
 - put a new subscriber count widget on blog
 - blog Build Command-Line Apps Like a Pro Using Ruby and Escort
 
+
+- in trollop when errors are raised they should be wrapped as escort errors and propagate rather than being caught by trollop itself DONE
 - rework the examples again to show of some/most of the features (along the lines of the integration tests and readme)  DONE
 - errors coming straigh out of configuration should still be caught by error handlers to only display stack trace when needed (refactor app create method) DONE
 - readme for a basic app with conflicting options    DONE
 - readme for a basic app with dependent options      DONE
 
 v1.0.1
-- more specs
+- pull out the action execution into a separate class and test it
+- add a section to readme for command line tools built with escort (e.g. ppjson)
+- more specs (all the dsl classes possibly)
 - more integration specs (more specs for the different types of options)
-- lots more logging at different levels for debug purposes
 - a way have helpers available when you don't want to have to create a command
-- the config auto option should not be included in the config file, same with other auto options
+- the config auto option should not be included in the config file, same with other auto options???
 - readme about how to actually pass the user config through to action and the fact that regardless if you have a config file or not, you can have a config var or not as part of the block variables
-- ability to specify a different command based on options declaratively or a convention for how to do different things for the same action based on options (bunch of options that are flags, options that are a clump of values etc)
+
 
 - rework the integration specs and matchers so there are less moving parts (perhaps push some stuff down into a base class etc.) DONE
 - rewrite the help formatter to be a bit easier to understand (more like man output for output) DONE
 - add depends support to dsl   DONE
 
 v1.0.2
+- refactor the app class so it is a bit nicer etc
 - more specs
+- need a suite for escort itself using escort to bootstrap etc
 - scaffold for app with no sub commands
 - scaffold for app with one level of commands
 - scaffold for app with nested sub commands
@@ -115,13 +90,32 @@ v1.0.3
 - make the configuration environment aware
 - make escort environment aware (app.environment_aware)
 - json configuration should support defaults config
-- much better documentation and usage patterns
 - pull the terminal formatting stuff into separate gem
+- pull nested exception stuff into separate gem
+
+
+- much better documentation and usage patterns         DONE
+
+v2.0.0
+- rework actions with passing a class and having it being auto called
+- implement servants for dealing with clumps of functionality, and action commands have access to all servants that were executed before them
+- ability to break up a big config into chucks, e.g. per command etc. so that it is more modular and easier to read
+- whether or not action is specified things should not blow up
 
+v2.0.1
+- lots more logging at different levels for debug purposes
 
 
 
 BUCKET
+- get all tests passing on jruby 1.9
+- get all tests passing on rubinius 1.9
+- get all tests passing on mri 1.8.7
+- configatron support in addition to json config
+- for help current command context is all confused, is the context a parent context or the current context, fixed in help but the class is still confused as it's being used in two different ways
+- genericise the generator concept, so that the current one becomes a nested generator, but we can also have a flat generator
+- genericise the writer and reader, so that the current one becomes json writer/reader, but we can have yaml or whatever we want
+- we should always be working with a nested hash for configuration, its only at writing and reading time do we flatten or whatever
 - dependencies for command options on options from parent commands or global
 - a better way of executing action and servants for the actions
 
@@ -142,6 +136,7 @@ BUCKET
     app.before :actions => :descendant - all actions that descend from this one, but not this one
 
 - can split out the shell command executor into a tiny gem for later use
+- for borderless table, should be able to create another borderless table within a cell of an existing table
 - get the build working on ruby 1.8.7
 - formatting code should support colours and styles for output
 - formatting code should support a table with borders and stuff
@@ -263,3 +258,55 @@ v0.1.0
 - look again at conflicts support in dsl, we can probably do better naming for it   DONE
 - up the version to 0.1.0                                                           DONE
 - tag and release                                                                   DONE
+
+v0.2.0
+- up the version to 0.2.0 DONE
+- tag and release DONE
+- test conflicts for non-exstant options (integration) DONE
+- test all the new help stuff on option, for conflicts, dependencies, validations DONE
+- fix up readme for conflicts block    DONE
+- rework validations to be part of the options block rather than in their own block  DONE
+- fix example, fix tests, fix readme DONE
+- need to rework conflicts as currently not really very good   DONE
+- add dependencies to help text  DONE
+- add conflicts to help text     DONE
+- add validation texts to help text so that people can see what kind of values are valid  DONE
+- make sure we check conflicts for non-existant options   DONE
+- refactor the formatting code some more DONE
+- pull some formatting code into separate classes DONE
+- test some of the utility formatting code DONE
+- fix up help text so that if arguments are mandatory they are shown as mandatory not optional DONE
+- basic example with validations       DONE
+- integration test for validations     DONE
+- readme for validations               DONE
+- test the shell command executor, and the terminal class for width command DONE
+- improve the readme to explain
+  - a basic app with no options                                 DONE
+  - a basic app with options                                    DONE
+    - supplying multiple of the same parameter using multi      DONE
+  - a basic app with require arguments                          DONE
+  - a basic app specifying version, description and summary     DONE
+  - test the readme for flags to make sure it works as expected DONE
+  - a basic app with dependant options (mention that a deadlock situation can occur if you're not careful)  DONE
+- example for conflicting options                            DONE
+- integration test for conflicting options                   DONE
+- readme for conflicting options                             DONE
+- for print stacktrace, change it to print in INFO mode so that stacktrace not printed by default DONE
+- BUG when a script requires arguments and user doesn't supply any escort treats this as an internal error and asks you to report it, this shouldn't be the case DONE
+- depends_on support
+  - option depends on flag                                                                      DONE
+  - flag depends on another flag                                                                DONE
+  - one option depends on another (the other must be not false not nil and not empty)           DONE
+  - one option depends on specific value of another (the other must be of a specific values)    DONE
+  - one option depends on several others (where are must be not false not nil and not empty)    DONE
+  - one option depends on several others where some must have a specific value (some options have specific value, others are not false not nil and not empty)  DONE
+  - error if option for which dependecy is being defined does not exist                         DONE
+  - error if depends on non-existant option                                                     DONE
+  - error if depends on itself                                                                  DONE
+  - error if dependency not satisfied                                                           DONE
+  - error if missing on condition when specifying dependency                                    DONE
+  - refactor the options dsl class dependency code                                              DONE
+  - refactor the option_dependency_validator class to be nicer                                          DONE
+  - integration test all the permutations of dependency specification with error and success cases etc  DONE
+  - create a shortcut for dependency specification on the opt method options hash itself                DONE
+  - fix up example for basic app with dependencies for options                                          DONE