tap 0.11.1 → 0.12.0

data/History

@@ -1,3 +1,38 @@
+== 0.12.0 / 2009-02-17
+
+As of the 0.12.0 release, Tap is distributed as several independent modules
+which can be collectively installed through tap-suite.  Tap has been cleaned
+up significantly since the 0.11 series, and some changes are not backwards
+compatible.  The main task API has been preserved.
+
+Notable changes include:
+
+* Lazydoc, Configurable, Rap, and Tap generators are now
+  independent gems.  Install the whole suite via tap-suite
+* Removed use of OptionParser
+* Root#directories was refactored to Root#relative_paths
+* Added several methods to Root
+* Added splat option for joins
+* Refactored stack short option to 'k'
+* Reworked Sequence, Fork, and Merge as special cases of Join
+* Reworked Audit as a directed acyclic graph
+* Cleanup and extension of FileTask API
+* Removed RSpec support
+* Added Mini::Test support
+* Added/clarified Task nesting
+* Removed batching from Executable (neat feature but complex in joins)
+* The tap executable longer automatically reconfigures tasks from config files
+
+Upgrade note:
+
+* Root#directories was refactored to Root#relative_path, so the file_test
+  :directories option needs to be updated to :relative_paths
+* Several test methods were removed in favor of better alternatives through
+  method_root itself.  In particular method_tempfile('path') should be
+  replaced with method_root.prepare(:tmp, 'path').
+* EnvVars#env was refactored to EnvVars#env_var to prevent a common collision
+  with env as a test variable.
+
 == 0.11.0 / 2008-10-20
 
 Significant update to Tap with many internal reworks.
@@ -87,4 +122,3 @@ Documentation is still patchy, but improving.
 == 0.7.9 / 2007-09-14
 
 * Initial testing release with partial documentation
-

data/MIT-LICENSE

@@ -1,4 +1,4 @@
-Copyright (c) 2006-2008, Regents of the University of Colorado.
+Copyright (c) 2006-2009, Regents of the University of Colorado.
 
 Permission is hereby granted, free of charge, to any person obtaining a copy of this
 software and associated documentation files (the "Software"), to deal in the Software

data/README

@@ -1,5 +1,7 @@
 = {Tap (Task Application)}[http://tap.rubyforge.org]
 
+  tap n. to draw a supply from a resource
+
 A framework for creating configurable, distributable tasks and workflows.
 
 == Description
@@ -23,7 +25,9 @@ Check out these links for tutorials, development, and bug tracking.
   but play well together. See the {Tutorial}[link:files/doc/Tutorial.html].
 - Tap is tested on MRI (the standard Ruby interpreter, versions 1.8.6 and 
   1.9.0) and JRuby[http://jruby.codehaus.org/].
-
+- Tap is the core of the {Tap-Suite}[http://tap.rubyforge.org/tap-suite], a
+  collection of several modules that simplify development.
+  
 === Usage
 
 A simple task illustrates the usage of tap:
@@ -50,8 +54,7 @@ Tap pulls documentation out of task classes to generate manifests:
     tap:
       dump        # the default dump task
       load        # the default load task
-      rake        # run rake tasks  
-
+      
 And help:
 
   % tap run -- goodnight --help
@@ -65,31 +68,28 @@ And help:
           --message MESSAGE            a goodnight message
 
   options:
-      -h, --help                       Print this help
-          --name NAME                  Specify a name
-          --use FILE                   Loads inputs from file
+          --help                       Print this help
+          --name NAME                  Specifies the task name
+          --config FILE                Specifies a config file
+          --use FILE                   Loads inputs to ARGV
 
-
-Tasks are immediately available to run through tap or rap:
+Tasks are immediately available to run through the tap executable:
 
   % tap run -- goodnight moon
     I[00:09:55]          goodnight moon
-  
-  % rap goodnight moon --message hello
-    I[00:10:01]              hello moon
 
 Tap comes with generators. To get started:
 
   % tap generate root sample
   % cd sample
   % tap generate task goodnight
-  % rap goodnight moon
+  % tap run -- goodnight moon
 
 === Bugs/Known Issues
 
 - Some inconsequential tests on JRuby fail due to bugs in JRuby itself.
 - Joins, Parser, and Schema require additional documentation and may be
-  internally reworked.  The workflow syntax should remain the same.
+  reworked in a future release.  The workflow syntax should remain the same.
 
 == Installation
 
@@ -97,14 +97,15 @@ Tap is available as a gem on RubyForge[http://rubyforge.org/projects/tap].  Use:
 
   % gem install tap
 
-Tap requires an updated version of RubyGems[http://docs.rubygems.org/] (>= 1.2.0).  To check the version and update RubyGems:
+Tap requires an updated version of RubyGems[http://docs.rubygems.org/] 
+(>= 1.2.0).  To check the version and update RubyGems:
 
   % gem --version
   % gem --update system
 
 == Info 
 
-Copyright (c) 2006-2008, Regents of the University of Colorado.
+Copyright (c) 2006-2009, Regents of the University of Colorado.
 Developer:: {Simon Chiang}[http://bahuvrihi.wordpress.com], {Biomolecular Structure Program}[http://biomol.uchsc.edu/], {Hansen Lab}[http://hsc-proteomics.uchsc.edu/hansenlab/] 
 Support:: CU Denver School of Medicine Deans Academic Enrichment Fund
 Licence:: {MIT-Style}[link:files/MIT-LICENSE.html]

data/bin/tap

@@ -59,7 +59,7 @@ end
 begin
   env.activate
   env.execute(ARGV) do
-    puts Tap::Support::Lazydoc.usage(__FILE__)
+    puts Lazydoc.usage(__FILE__)
     puts
     puts "available commands:"
     puts env.summarize(:commands)

data/cmd/console.rb

@@ -1,18 +1,19 @@
 # tap console {options}
 #
 # Opens up an IRB session with Tap initialized to the configurations 
-# in tap.yml. Access the Tap::App.instance through 'app'.
+# in tap.yml. Access the Tap::App.instance through 'app', and
+# Tap::Env.instance through 'env'.
 
 #
 # handle options
 #
 
-OptionParser.new do |opts|
+ConfigParser.new do |opts|
   opts.separator ""
   opts.separator "options:"
 
   opts.on("-h", "--help", "Show this message") do
-    opts.banner = Tap::Support::Lazydoc.usage(__FILE__)
+    puts Lazydoc.usage(__FILE__)
     puts opts
     exit
   end

data/cmd/manifest.rb

@@ -4,13 +4,13 @@
 #
 
 options = {}
-OptionParser.new do |opts|
+ConfigParser.new do |opts|
   
   opts.separator ""
   opts.separator "options:"
 
   opts.on("-h", "--help", "Show this message") do
-    opts.banner = Tap::Support::Lazydoc.usage(__FILE__)
+    puts Lazydoc.usage(__FILE__)
     puts opts
     exit
   end

data/cmd/run.rb

@@ -13,29 +13,27 @@ app = Tap::App.instance
 #
 
 dump = false
-OptionParser.new do |opts|
+ConfigParser.new do |opts|
   opts.separator ""
   opts.separator "configurations:"
   
-  Tap::App.configurations.each do |receiver, key, config|
-    next if receiver == Tap::Root
-    
-    opts.on(*config.to_optparse_argv) do |value|
-      app.send(config.writer, value)
-    end
+  root_keys = Tap::Root.configurations.keys
+  Tap::App.configurations.each_pair do |key, config|
+    next if root_keys.include?(key)
+    opts.define(key, config.default, config.attributes)
   end
  
   opts.separator ""
   opts.separator "options:"
-
+ 
   opts.on("-h", "--help", "Show this message") do
-    opts.banner = Tap::Support::Lazydoc.usage(__FILE__)
     Tap::App.lazydoc.resolve
+    puts Lazydoc.usage(__FILE__)
     puts opts
     exit
   end
   
-  opts.on('-T', '--manifest', 'Print a list of available tasks') do |v|
+  opts.on('-T', '--manifest', 'Print a list of available tasks') do
     puts env.summarize(:tasks)
     exit
   end
@@ -46,14 +44,13 @@ end.parse!(ARGV)
 # build and run the argv
 #
 
-queues = env.build(ARGV)
+env.set_signals
+env.build(ARGV)
 ARGV.clear
 
-if queues.empty?
+if app.queue.empty?
   puts "no task specified"
   exit
 end
 
-env.set_signals
-env.run(queues)
-
+app.run

data/doc/Class Reference

@@ -1,6 +1,7 @@
 = Class Reference
 
-Working up from the ground is useful to get a sense for how Tap does what it does.  This reference goes through the modules and classes that build up a task application: Tasks, Apps, and Envs.
+This is a ground-up overview of the main classes and modules used by Tap,
+specifically Tasks, Apps, and Envs.
 
 == Tasks
 
@@ -8,26 +9,33 @@ Working up from the ground is useful to get a sense for how Tap does what it doe
 
 http://tap.rubyforge.org/images/Method.png
 
-Tasks begin with methods, simply a block of code.
+Tasks are fundamentally just a method, simply a block of code.
 
 ==== Tap::Support::Executable
 
 http://tap.rubyforge.org/images/Executable.png
 
-Executable extends objects allowing them to be used in workflows, enqued, and run by an App.  Executable objects specify a method that gets called upon execution; in essence Executable wraps this method and adds workflow support for dependencies, joins, batches, and auditing.  Any method may be made executable, and so any method can participate in a workflow (see Object#_method).
+Executable essentially wraps a method and adds support for dependencies, joins,
+and auditing.  Executables are the nodes in a workflow.  Any Executable may be
+joined to another Executable, enqued, and run by an App.  To wrap a method,
+Executable extends an object and defines which method on the object is 'executable'.
+Any method may be made executable, and so any method can participate in a workflow
+(see Object#_method).
 
-Tasks are constructed such that <tt>process</tt> is the executable method (actually execute_with_callbacks is used to wrap process with before/after execute callbacks, but effectively this is the case).  Hence <tt>process</tt> is the standard method overridden in Task subclasses.
+Tasks are constructed such that <tt>process</tt> is the executable method, hence
+<tt>process</tt> is the standard method overridden in Task subclasses.
 
-==== Tap::Support::Configurable
+==== {Configurable}[http://tap.rubyforge.org/configurable/]
 
 http://tap.rubyforge.org/images/Configurable.png
 
-Configurable allows declaration of class configurations.  Configurable classes have a <tt>configurations</tt> method accessing a {ClassConfiguration}[link:classes/Tap/Support/ClassConfiguration.html] which holds all declared configs, their default values, and metadata for transforming configurations into command line options (for example).  
-
-Instances of a Configurable class have a <tt>config</tt> method accessing a {InstanceConfiguration}[link:classes/Tap/Support/InstanceConfiguration.html] object.  The instance configuration acts like a forwarding hash; read and write operations for declared configs get forwarded to class methods while undeclared configs are stored directly.  The writer for a config may be defined through a block provided during config declaration.  For instance:
-
+Tap uses the {Configurable}[http://tap.rubyforge.org/configurable/] module to
+declare class configurations and make them available on the command line.
+Configurations are essentially a shorthand to define attributes with a default
+value.  For instance:
+  
   class ConfigClass
-    include Tap::Support::Configurable
+    include Configurable
 
     config :key, 'value' do |input|
       input.upcase
@@ -52,7 +60,8 @@ Is basically the same as:
     end
   end
 
-As you can see here:
+Configurations may be accessed through a hash-like config object, as you can
+see here:
 
   c = ConfigClass.new
   c.key                       # => 'VALUE'
@@ -63,14 +72,22 @@ As you can see here:
   c.key = 'another value'
   c.config[:key]              # => 'ANOTHER VALUE'
 
-This setup is both fast and convenient.  
+This setup is both fast and convenient. See the {Configurable}[http://tap.rubyforge.org/configurable]
+documentation for more information.
 
-==== Tap::Support::Validation
+==== {Configurable::Validation}[http://tap.rubyforge.org/configurable/classes/Configurable/Validation.html]
 
-When configurations are set from the command line, the writer method will inevitably receive a string, whereas configurations set within code can receive any type of object.  The {Validation}[link:classes/Tap/Support/Validation.html] module provides standard blocks for validating and transforming inputs, accessible through the <tt>c</tt> method (ex: <tt>c.integer</tt> or <tt>c.regexp</tt>).  These blocks (generally) load string inputs as YAML and validate that the result is the correct class; non-string inputs are simply validated.
+When configurations are set from the command line, the config writer inevitably
+receives a string, even though you may want a non-string input.  The
+{Validation}[http://tap.rubyforge.org/configurable/classes/Configurable/Validation.html]
+module provides standard blocks for validating and transforming inputs, and
+may be accessed through the shortcut method <tt>c</tt> (ex: <tt>c.integer</tt>
+or <tt>c.regexp</tt>).  Validation blocks (generally) load string inputs as
+YAML and validate that the result is the correct class; non-string inputs are
+simply validated.
 
   class ValidatingClass
-    include Tap::Support::Configurable
+    include Configurable
 
     config :int, 1, &c.integer                 # assures the input is an integer
     config :int_or_nil, 1, &c.integer_or_nil   # integer or nil only
@@ -87,74 +104,68 @@ When configurations are set from the command line, the writer method will inevit
 
   vc.array = "string"                          # !> ValidationError
 
-Validation blocks sometimes imply metadata.  For instance <tt>c.flag</tt> makes a config into a flag on the command line.
+Validation blocks sometimes imply metadata.  For instance <tt>c.flag</tt> makes
+a config into a flag on the command line.
 
-==== Tap::Support::Lazydoc
+==== {Lazydoc}[http://tap.rubyforge.org/lazydoc]
 
-Ah lazydoc.  Lazydoc fits into the space between live code and code documentation.  Lazydoc can scan a file (code or not) and pull documentation into the object space where it can be utilized.  Lazydoc uses a key-value syntax like this:
+{Lazydoc}[http://tap.rubyforge.org/lazydoc] fits into the space between live
+code and code documentation.  Lazydoc can scan a file and pull documentation
+into the object space, typically via a syntax like this:
 
-  # ::key value
+  # Constant::key value
+  # comment
 
-Lazydoc parses a constant name, the key, the value, and any comment following the value until a non-comment line or an end key.  For example:
+For example:
 
   [lazydoc_file.rb]
-  # Name::Space::key value
+  # Const::Name::key value
   # 
-  # This documentation
-  # gets parsed.
-  #
-
-  # Name::Space::another another value
-  # This gets parsed.
-  # Name::Space::another-
+  # This is an extended,
+  # multiline comment.
   #
-  # This does not.
 
   require 'tap'
 
-  lazydoc = Tap::Support::Lazydoc[__FILE__]
+  lazydoc = Lazydoc[__FILE__]
   lazydoc.resolve
-
-  lazydoc['Name::Space']['key'].to_s           # => "This documentation gets parsed."
-  lazydoc['Name::Space']['another'].value      # => "another value"
-
-Furthermore, Lazydoc can register specific lines for documentation.  These lines are parsed to echo what happens in RDoc.
-
-  [another_lazydoc_file.rb]
-  # documentation
-  # for the method
-  def method
+  
+  lazydoc['Const::Name']['key'].value          # => "value"
+  lazydoc['Const::Name']['key'].comment        # => "This is an extended, multiline comment."
+
+Lazydoc can also register specific lines for documentation, like method
+definitions or configurations.  Tap uses Lazydoc to identify files that contain
+tasks and generators, to extract config documentation, and to infer the args
+arguments a task receives.  Here is an example of information gleaned from a
+task definition:
+
+  # Sample::manifest a summary of the task
+  class Sample < Tap::Task
+    config :key, 'value'   # a simple configuration
+    
+    def process(a, b='B', *c)
+    end
   end
-
-  require 'tap'
-
-  lazydoc = Tap::Support::Lazydoc[__FILE__]
-  code_comment = lazydoc.register(2)
-  lazydoc.resolve
   
-  code_comment.subject         # => "def method"
-  code_comment.to_s            # => "documentation for the method"
-
-Tap uses Lazydoc to indicate when a file contains a Task (<tt>::manifest</tt>) or a generator (<tt>::generator</tt>), and for config documentation.  Tap::Env uses this information to facilitate lookup and instantiation of task classes.  
-
-When no constant name is specified for a Lazydoc key, Env uses a constant based on the file name.
-
-  [lib/sample/task.rb]
-  # ::manifest sample task description
-  #
-  # This manifest is expected to apply to the Sample::Task class.
-  # If more than one task is defined in this file, or if Sample::Task
-  # is not defined by loading this file, Tap will run into trouble.
-
-However, the best practice is to include the namespace explicitly.
+  Sample::manifest.to_s                        # => "a summary of the task"
+  Sample::args.to_s                            # => "A B='B' C..."
+  
+  key = Sample.configurations[:key]
+  key.attributes[:desc].to_s                   # => "a simple configuration"
+  
+See the {Lazydoc}[http://tap.rubyforge.org/lazydoc] documentation for more
+information.
 
 === Tap::Task
 
 http://tap.rubyforge.org/images/Task.png
 
-Running a task from the command line using tap (or rap) instantiates a task, configures it, enques it, and runs an App to pass inputs to the <tt>process</tt> method.  Tasks do not have to be used this way; they are perfectly capable as objects in free-standing scripts.
+Tasks are the bread and butter of Tap.  Tasks act as the nodes in workflows and,
+using the Configurable and Lazydoc metadata, map to the command line as miniature
+applications.  That said, tasks are perfectly useful as ordinary objects.
 
-Task instances may be interned with a block that acts as a stand-in for <tt>process</tt>:
+When subclassing is too much, tasks may be interned with a block that effectively
+replaces <tt>process</tt>:
 
   t = Tap::Task.intern {|task| 1 + 2 }
   t.process                # => 3
@@ -175,46 +186,36 @@ joined into dependency-based workflows,
   t0 = Tap::Task.intern {|task| runlist << task }
   t1.depends_on(t0)
 
-imperative workflows,
+and imperative workflows.
 
   t2 = Tap::Task.intern do |task, input|
     runlist << task
     "#{input}:two"
   end
   t1.sequence(t2)
-
-and batched.
-
-  t3 = t1.initialize_batch_obj(:key => 'three')
-  t1.batch                 # => [t1, t3]
   
-Batched tasks enque together, and therefore execute sequentially with the same inputs. Results are aggregated into the underlying Tap::App.
+Results are aggregated into the underlying Tap::App.
 
   t1.enq('input')
   
   app = Tap::App.instance
   app.run
   
-  runlist                  # => [t0, t1, t2, t3, t2]
-  app.results(t2)          # => ["input:one:two", "input:three:two"]
+  runlist                  # => [t0, t1, t2]
+  app.results(t2)          # => ["input:one:two"]
 
-Tracking the evolution of a result through a workflow can get complex; Tap audits workflows to help.  In the audit trail, the tasks are identified by name.  Lets set the names of the tasks and take a look at the audit trails of the t2 results:
+Tracking the evolution of a result through a workflow can get complex.  Tap
+audits workflows to help.  Setting the names of the tasks will identify them
+in an audit dump:
 
   t1.name = 'un'
   t2.name = 'deux'
-  t3.name = 'trois'
   
-  app._results(t2).collect do |_result|
-    _result._to_s
-  end.join("---\n")
+  app._results(t2)[0].dump
   # => 
   # o-[] "input"
   # o-[un] "input:one"
   # o-[deux] "input:one:two"
-  # ---
-  # o-[] "input"
-  # o-[trois] "input:three"
-  # o-[deux] "input:three:two"
 
 == Apps
 
@@ -222,47 +223,39 @@ Tracking the evolution of a result through a workflow can get complex; Tap audit
 
 http://tap.rubyforge.org/images/Root.png
 
-A Root represents the base of a directory structure. Roots allow you to alias directories and ease working with filepaths, basically allowing you to develop code for a conceptual directory structure that can be defined later.
+A Root represents the base of a directory structure. Roots allow you to alias
+relative paths, basically allowing you to develop code for a conceptual
+directory structure that can be defined later.
 
   root = Tap::Root.new '/path/to/root'
   root.root                                      # => '/path/to/root'
   root['config']                                 # => '/path/to/root/config'
   root.filepath('config', 'sample.yml')          # => '/path/to/root/config/sample.yml'
 
-While simple, this ability to alias paths is useful, powerful, and forms the basis of the Tap execution environment.
+While simple, this ability to alias paths is useful, powerful, and forms the
+basis of the Tap execution environment.
 
 ==== Tap::Support::ExecutableQueue
 
 http://tap.rubyforge.org/images/ExecutableQueue.png
 
-Apps coordinate the execution of tasks through a queue.  The queue is just a stack of Executable objects, basically methods, and the inputs to those methods; during a run the enqued methods are sequentially executed with the inputs.
-
-==== Tap::Support::Dependencies
-
-Dependencies coordinate the registration and resolution of dependencies, which may be shared across multiple tasks.
-
-==== Tap::Support::Audit
-
-Tap tracks inputs as they are modified by various tasks, again through Executable.  At the end of a run, any individual result can be tracked back to it's original value with references to the source of each change (ie the task).  This auditing can be very useful when workflows diverge, as they often do.
-
-Auditing is largely invisible except in <tt>on_complete</tt> blocks.  <tt>on_complete</tt> blocks receive the audited results so that this information can be used, as needed, to make decisions.  
-
-    Task.new.on_complete do |_result|            # _result is an Audit instance
-      _result._current                           # the current value
-      _result._original                          # the original value
-    end
-
-To help indicate when a result is actually a result and when it is an audit, Tap uses a convention whereby a leading underscore signals auditing is involved.
-
-==== Tap::Support::Aggregator
-
-When a task completes, it executes it's <tt>on_complete</tt> block to handle the results, perhaps passing them on to other tasks.  Aggregators collect results when no <tt>on_complete</tt> block is specified.  Results are collected per-task into an array; a single task executed many times will have it's results aggregated into this single array.
+Apps coordinate the execution of tasks through a queue.  The queue is just a
+stack of Executable objects, basically methods, and the inputs to those 
+methods; during a run the enqued methods are sequentially executed with the 
+inputs.
 
 === Tap::App
 
 http://tap.rubyforge.org/images/App.png
 
-Instances of Tap::App coordinate the execution of tasks.  Apps are basically a subclass of Root with an ExecutableQueue, Dependencies, and an Aggregator.  Task initialization requires an App, which is by default Tap::App.instance.  Tasks use their app for logging, dependency-resolution, checks, and to enque themselves.  Normally a script will only need and use a single instance (often Tap::App.instance), but there is no reason why multiple instances could not be used.  
+Instances of Tap::App coordinate the execution of tasks.  Apps are basically a
+subclass of Root with an ExecutableQueue.
+
+Task initialization requires an App, which is by default Tap::App.instance.  
+Tasks use their app for logging, dependency-resolution, checks, and to enque 
+themselves.  Normally a script will only need and use a single instance (often
+Tap::App.instance), but there is no reason why multiple instances could not be
+used.  
 
   log = StringIO.new
   app = Tap::App.instance
@@ -282,7 +275,8 @@ Instances of Tap::App coordinate the execution of tasks.  Apps are basically a s
   app.run
   app.results(t)             # => [[1], [2,3]]
   
-As shown, apps also aggregate results for tasks, which is important for workflows.
+As shown, apps also aggregate results for tasks, which is important for
+divergent workflows.
 
 == Envs 
 
@@ -290,7 +284,9 @@ As shown, apps also aggregate results for tasks, which is important for workflow
 
 http://tap.rubyforge.org/images/Env.png
 
-Basically a wrapper for a Root, Envs define methods to generate manifests for a type of file-based resource (tasks, generators, etc).  Furthermore they provide methods to uniquely identify the resource by path or, more specifically, minimized base paths.  In this directory structure:
+Envs generate manifests of various resources (tasks, generators, etc) and 
+provide methods to uniquely identify resources using minimized base paths.
+In this directory structure:
 
   path
   `- to
@@ -307,11 +303,17 @@ The minimal paths that uniquely identify these files are (respectively):
   'file-0.2.0'
   'file.rb'
 
-Envs facilitate mapping the minimal path, which might be provided by the command line, to the actual path, and hence to the resource.  Envs can be nested so that manifests span multiple directories.  Indeed, this is how tap accesses tasks and generators within gems; the gem directories are initialized as Envs and nested within the Env for the working directory.
+Envs facilitate mapping a minimal path to an actual path, and hence to a
+resource.  Envs can be nested so that manifests span multiple directories.
+Indeed, this is how tap accesses tasks and generators within gems; the gem
+directories are initialized as Envs and nested within the Env for the working
+directory.
 
 http://tap.rubyforge.org/images/Nested-Env.png
 
-To prevent conflicts between similarly-named resources under two Envs, Env allows selection of Envs, also by minimized paths.  Say you installed the 'sample_tasks' gem.
+To prevent conflicts between similarly-named resources under different Envs,
+Env allows selection of Envs, also by minimized paths.  Say you installed the
+'sample_tasks' gem.
 
   % tap manifest
   --------------------------------------------------------------------------------
@@ -349,7 +351,10 @@ To prevent conflicts between similarly-named resources under two Envs, Env allow
   |- sample_tasks 
   `- tap 
 
-In this printout of the manifest, you can see the resources available to tap on the Desktop (none), in the sample_tasks gem, and in tap itself.  Since there aren't any conflicts among tasks, the minipath of any of the tasks is sufficient for identification:
+In this printout of the manifest, you can see the resources available to tap on
+the Desktop (none), in the sample_tasks gem, and in tap itself.  Since there
+aren't any conflicts among tasks, the minipath of any of the tasks is sufficient
+for identification:
 
   % tap run -- print_tree
   % tap run -- dump
@@ -358,14 +363,12 @@ If there were a conflict, you'd have to specify the environment minipath like:
 
   % tap run -- sample_tasks:print_tree
   % tap run -- tap:dump
-  
-Note the same rules apply for rap:
-
-  % rap print_tree
-  % rap tap:dump
 
 ==== Tap::Exe
 
 http://tap.rubyforge.org/images/Run-Env.png
 
-The tap (and rap) executable environment.  Tap::Exe adds several configurations (ex before/after) which only get loaded for the present directory, and methods for building and executing workflows from command line inputs.  Tap::Exe is a singleton, and is special because it wraps Tap::App.
+Tap::Exe adds several configurations (ex before/after) which only get loaded
+for the present directory, and methods for building and executing workflows
+from command line inputs.  Tap::Exe is a singleton, and is special because it
+wraps Tap::App.instance.