tap 0.11.1 → 0.12.0

data/doc/Command Reference

@@ -1,18 +1,14 @@
 = Command Reference
 
-Tap comes with two executables: tap (a gateway application) and rap (a shortcut for running tasks).  The syntax for running tasks via 'tap run' and rap is covered in the {Syntax Reference}[link:files/doc/Syntax%20Reference.html]; this reference covers all of the other tap commands.  For help on the command line, type:
+Tap comes the tap executable.  For help on the command line, type:
 
   % tap --help
 
-=== configuration
+== console
 
-Tap sets up the local execution environment from 'tap.yml', if it exists.  The config file is, as the extension implies, a YAML file and will be automatically created by the root generator.  Naturally, you can create it yourself.  See Tap::Env and Tap::Exe for a list of the available configurations.
-
-In addition, default configurations may be specified in the global configuration file '~/.tap.yml', where '~' is evaluated as Gem.user_home.
-
-== tap console
-
-Console opens an irb session after loading the tap environment.  Console defines variables 'app' and 'env' referencing Tap::App.instance and Tap::Env.instance, for easy access.
+Console opens an irb session after loading the tap environment.  Console
+defines variables 'app' and 'env' referencing Tap::App.instance and
+Tap::Env.instance, for easy access.
 
   % tap console
   irb(main):001:0> app.log(:hello)
@@ -20,13 +16,13 @@ Console opens an irb session after loading the tap environment.  Console defines
   => true
   irb(main):002:0>
 
-== tap generate/destroy
+== generate/destroy
 
-Generate and destory launch generator scripts, similar to those in {Rails}[http://www.rubyonrails.org/].  By default Tap provides generators for:
+Generate and destroy launch generator scripts, similar to those in 
+{Rails}[http://www.rubyonrails.org/].  By default Tap provides generators for:
 
 {command}[link:classes/Tap/Generator/Generators/CommandGenerator.html]:: a new command
 {config}[link:classes/Tap/Generator/Generators/ConfigGenerator.html]:: a static config file for the specified task
-{file_task}[link:classes/Tap/Generator/Generators/FileTaskGenerator.html]:: a file task and test
 {generator}[link:classes/Tap/Generator/Generators/GeneratorGenerator.html]:: a new generator
 {root}[link:classes/Tap/Generator/Generators/RootGenerator.html]:: the basic directory structure
 {task}[link:classes/Tap/Generator/Generators/TaskGenerator.html]:: a task class and test
@@ -36,7 +32,7 @@ For example:
   % tap generate root .
   % tap generate task sample_task
   % tap generate config sample_task
-  
+
   % tap destroy config sample_task
   % tap destroy task sample_task
   % tap destroy root .
@@ -45,10 +41,13 @@ Each generator works a little differently.  For help:
 
   % tap generate --help
   % tap generate <generator> --help
-  
-== tap manifest
 
-Manifest prints a list of all resources (commands, tasks, generators, etc) available to tap.  Environments are listed in the same order as they are searched, and at the end a tree diagram is printed showing how the environments are nested.
+== manifest
+
+Manifest prints a list of all resources (commands, tasks, generators, etc)
+available to tap.  Environments are listed in the same order as they are
+searched, and at the end a tree diagram is printed showing how the
+environments are nested.
 
   % tap manifest
   --------------------------------------------------------------------------------
@@ -58,7 +57,6 @@ Manifest prints a list of all resources (commands, tasks, generators, etc) avail
     generators
       command        (lib/tap/generator/generators/command/command_generator.rb)
       config         (lib/tap/generator/generators/config/config_generator.rb)
-      file_task      (lib/tap/generator/generators/file_task/file_task_generator.rb)
       generator      (lib/tap/generator/generators/generator/generator_generator.rb)
       root           (lib/tap/generator/generators/root/root_generator.rb)
       task           (lib/tap/generator/generators/task/task_generator.rb)
@@ -77,18 +75,25 @@ Manifest prints a list of all resources (commands, tasks, generators, etc) avail
   Desktop
   `- tap
 
-== tap run
+== run
 
-Run configures, enqueues, and executes tasks.  Run has a rich syntax allowing the specification of any number of tasks with configurations and inputs, but simplifies under most circumstances.  The run syntax is detailed in the {Syntax Reference}[link:files/doc/Syntax%20Reference.html], but a couple examples illustrate the key points:
+Run configures, enqueues, and executes tasks.  Run has a rich syntax allowing
+the specification of any number of tasks with configurations and inputs, but
+simplifies under most circumstances.  The run syntax is detailed in the {Syntax Reference}[link:files/doc/Syntax%20Reference.html], but a couple examples
+illustrate the key points:
 
   % tap run sample/task 
   % tap run -- sample/task --key=value input_one -- another/task input_two
 
-The second statement specifies two tasks with inputs, and specifies a configuration for sample/task.  As can be seen, run separates tasks using a double-dash, the standard option break.  Options for the run command can be specified before the first break.
+The second statement specifies two tasks with inputs, and specifies a
+configuration for sample/task.  As can be seen, run separates tasks using a
+double-dash, the standard option break.  Options for the run command can be
+specified before the first break.
 
   % tap run --debug -- sample/task --key=value
 
-Here run receives the <tt>--debug</tt> option and sample/task receives the <tt>--key=value</tt> option.  Inputs work the same way.  For example:
+Here run receives the <tt>--debug</tt> option and sample/task receives the 
+<tt>--key=value</tt> option.  Inputs work the same way.  For example:
 
   % tap run -- sample/task --key=value one -- another/task two three
 
@@ -97,9 +102,4 @@ Specifies the following:
   Sample::Task.new(:key => 'value').enq('one')
   Another::Task.new.enq('two', 'three') 
 
-Any number of tasks, configurations, and inputs may be specified in this way.
-
---
-== tap server
-
-An experimental local server for tap tasks.
+Any number of tasks, configurations, and inputs may be specified in this way.

data/doc/Syntax Reference

@@ -1,81 +1,11 @@
 = Syntax Reference
 
-Tap uses several domain-specific languages to declare tasks and workflows.  This is a reference for:
+Tap uses several domain-specific languages to declare tasks and workflows.
+This is a reference for:
 
-* task declarations
 * class definitions
 * workflows
 
-== Task Declarations
-
-A task declaration:
-
-  # name::           the name of the task, either alone or as the
-  #                  key of a {key => dependencies} hash
-  # dependencies::   an array of task names (optional)
-  # arg_names::      an array of argument names (optional)
-  # configurations:: a hash of {key => default} pairs (optional)
-
-  task({<name> => [<dependencies...>]}, <arg_names...>, {<configs>}) do |task, args|
-    # arguments are available through args:
-    args.arg_name
-    
-    # configurations are available through task
-    task.key
-  end
-
-A namespace declaration:
-
-  namespace(<name>) { task ... }
- 
-Simple documentation:
- 
-  desc "description"
-  task ...
-  
-Extended documentation:
-  
-  # ::desc description
-  # Extended documentation may span multiple lines, and 
-  # supports
-  #
-  #   code indentation
-  #   like this.
-  #
-  # Lines are justified and wrapped on the command line.
-  task ...
-
-Pains were taken to make task declarations for rap work the similar to rake tasks.  In both cases (noting that in general, beyond rap, task classes are not limited in these ways):
-
-* tasks are singleton instances that may be extended across multiple declarations
-* tasks do not pass inputs from one task to the next
-* tasks only execute once
-
-A few syntactical differences between rake and rap must to be noted, as they can cause errors if you try to migrate rake tasks to tap.  Tap declarations.
-
-==== no needs
-
-Tasks do not support :needs as a way to specify dependencies.  For instance, this will declare a ':needs' configuration with the default value ':another', not a task which depends on another:
-
-  Tap.task :name, :needs => :another
-
-==== immediate namespace lookup
-
-Within a namespace, task will look for a literal match to the dependency first.  If it doesn't find one, it will declare it within the namespace; one way or the other the dependency is resolved immediately.  Hence, in this example the nested task depends on the non-nested task.  
-
-  task :outer { print 'non-nested' }
-  namespace :nest do
-    task :inner => :outer { puts 'was executed' }
-    task :outer { print 'nested' }
-  end
-  
-By contrast, rake waits to resolve dependencies and so will always use a match within a namespace in preference to a literal match.  For these tasks rap and rake produce different results:
-
-  % rap nest/inner
-  non-nested was executed
-  % rake nest:inner
-  nested was executed
-
 == Task Classes
 
 This is a verbose prototype for Tap::Task subclasses:
@@ -143,14 +73,21 @@ This is a verbose prototype for Tap::Task subclasses:
 
 == Workflows
 
-The tap workflow syntax is designed to specify an arbitrary number of tasks, inputs, configurations, and joins.  The syntax works both as text and as YAML; 'tap run' and rap both use it to specify which tasks to execute.  Basically, the syntax uses double-dash delimiters to separate task vectors and modified delimiters to specify joins for the tasks.  
+The tap workflow syntax is designed to specify an arbitrary number of tasks,
+inputs, configurations, and joins.  The syntax works both as text and as YAML;
+'tap run' uses it to specify which tasks to execute.  Basically, the syntax
+uses double-dash delimiters to separate task vectors and modified delimiters
+to specify joins for the tasks.  
 
 These both specify three tasks (x,y,z) joined in a sequence:
 
-  % rap x --: y --: z
-  % rap x -- y -- z --0:1:2
+  % tap run -- x --: y --: z
+  % tap run -- x -- y -- z --0:1:2
   
-The modified delimiters use numbers to indicate which tasks participate in a join and punctuation to indicate the join type.  In the first example, the numbers are implicitly added for the preceding and following task.  A variety of joins are supported:
+The modified delimiters use numbers to indicate which tasks participate in a
+join and punctuation to indicate the join type.  In the first example, the
+numbers are implicitly added for the preceding and following task.  A variety
+of joins are supported:
 
   delimiter  function         syntax                 example        meaning 
   --         delimiter                               a -- b -- c    enques/configures tasks a, b, c
@@ -165,11 +102,11 @@ The modified delimiters use numbers to indicate which tasks participate in a joi
 
 Inputs may be specified between delimiters:
 
-  % rap x alpha beta --: y gamma --: z delta
+  % tap run -- x alpha beta --: y gamma --: z delta
 
 As may be configurations, in a variety of formats:
 
-  % rap x alpha beta -k --: y gamma --key value --: z delta --key=value
+  % tap run -- x alpha beta -k --: y gamma --key value --: z delta --key=value
   
 These are the corresponding task vectors:
 
@@ -191,19 +128,30 @@ This is how it would look as YAML:
     - --key=value
   - 0:1:2
 
-The task vectors are converted into a task and an argument vector by first looking up a task class and then calling TaskClass.parse.  The parse method returns a configured instance of the task and an argv to be executed by the task.  Once the task are instantiated, instances are joined and enqued to Tap::App for execution (see Tap::Support::Schema#build).
+The task vectors are converted into a task and an argument vector by first
+looking up a task class and then calling TaskClass.parse.  The parse method
+returns a configured instance of the task and an argv to be executed by the
+task.  Once the task are instantiated, instances are joined and enqued to
+Tap::App for execution (see Tap::Support::Schema#build).
 
 ==== Class Lookup
 
-Tap looks up classes via Tap::Env.  Tap can find tasks from multiple environments; by adding in environments for gems, Tap can find tasks within a gem.
+Tap looks up classes via Tap::Env.  Tap can find tasks from multiple
+environments; by adding in environments for gems, Tap can find tasks
+within a gem.
 
-During lookup, classes are treated like filepaths which match from the basename up:
+During lookup, classes are treated like filepaths which match from the
+basename up:
 
   class             lookup              matched by
   Sample::Task      sample/task         task, sample/task
   A::Nested::Task   a/nested/task       task, nested/task, a/nested/task
 
-In the event of a name conflict, the path of the environment may also be specified.  It seems like this could get confusing, but the tap executable produces manifests that specify the minimal path required to uniquely identify a class.  Fragments of the minimized paths will be resolved in order from top to bottom within the specified environment.  For example: 
+In the event of a name conflict, the path of the environment may also be
+specified.  It seems like this could get confusing, but the tap executable
+produces manifests that specify the minimal path required to uniquely
+identify a class.  Fragments of the minimized paths will be resolved in order
+from top to bottom within the specified environment.  For example: 
 
   % tap run -T
   one:
@@ -234,57 +182,53 @@ Runs another/task:
   % tap run -- another/task
   % tap run -- one:another/task
 
-Notice that the full minimized path ('another/task') is required because simply using 'task' will be matched to sample/task.  The order of tasks is obviously not alphabetical -- rather it corresponds to the order in which Tap::Env discovers the tasks.
+Notice that the full minimized path ('another/task') is required because simply
+using 'task' will be matched to sample/task.  The order of tasks is obviously
+not alphabetical -- rather it corresponds to the order in which Tap::Env
+discovers the tasks.
 
 ==== Dependencies (--*)
 
-Normally each task vector specifies a new instance of a task.  This specifies three instance of the 'a' task.
+Normally each task vector specifies a new instance of a task.  This specifies
+three instance of the 'a' task.
 
-  % rap -- a -- a -- a
+  % tap run -- a -- a -- a
   
-When you want to specify a 'singleton' instance of a task, the instance specified by TaskClass.instance, use the dependency delimiter '--*'.  
+When you want to specify a 'singleton' instance of a task, the instance
+specified by TaskClass.instance, use the dependency delimiter '--*'.  
 
-  % rap --* a
+  % tap run --* a
   
-The dependency instance will be configured and enqued with the arguments.  Dependency instances will be executed first, even if they are specified at the end of a workflow, they cannot participate in workflows, and any single dependency may only be specified once in a workflow.  These are equivalent:
+The dependency instance will be configured and enqued with the arguments.
+Dependency instances will be executed first, even if they are specified at the
+end of a workflow, they cannot participate in workflows, and any single
+dependency may only be specified once in a workflow.  These are equivalent:
 
-  % rap --* a -- b -- c
-  % rap b -- c --* a
+  % tap run --* a -- b -- c
+  % tap run b -- c --* a
 
 While these raise errors:
 
-  % rap --* a --* a
-  % rap --* a --: b
+  % tap run --* a --* a
+  % tap run --* a --: b
 
 ==== Rounds (--+)
 
-The workflow syntax allows multiple execution rounds to be specified  All tasks in a round are run to completion before the next round begins.  Rounds are specified by adding '+' characters after the double-dash break.
+The workflow syntax allows multiple execution rounds to be specified  All tasks
+in a round are run to completion before the next round begins.  Rounds are
+specified by adding '+' characters after the double-dash break.
 
   % tap run -- round_one_task --+ round_two_task
 
-Tasks may be added to rounds in any order and may use the shorthand for multiple tasks.  These are equivalents:
+Tasks may be added to rounds in any order and may use the shorthand for multiple
+tasks.  These are equivalents:
 
   % tap run -- a --+ b --+ c --++ d
   % tap run --+ b --++ d -- a --+ c
   % tap run -- a -- b -- c -- d --+1[1,2] --+2[3]
 
-Rounds are particularly useful for dump tasks; add a dump task as a final round to capture all results from previous rounds:
+Rounds are particularly useful for dump tasks; add a dump task as a final round
+to capture all results from previous rounds:
 
   % tap run -- task -- task --+ dump
 
-==== Notes for rap
-
-Specifying tasks for rap is no different than 'tap run'.  The only exception occurs when the task can't be found.  Unknown tasks are implicitly run as a Tap::Tasks::Rake task, which causes the task to be run as if by rake.  These are the same:
-
-Run a rake task with inputs and an ENV config:
-
-  % rake task_name[1,2,3] key=value
-
-Explicitly run a Tap::Tasks::Rake task using the same inputs:
-
-  % rap rake task_name[1,2,3] key=value
-  
-Implicitly run the Tap::Tasks::Rake task:
-
-  % rap task_name[1,2,3] key=value
-

data/doc/Tutorial

@@ -1,16 +1,26 @@
 = Tap (Task Application)
 
-Tap is a framework for creating configurable, distributable tasks and workflows.  Although scalable for complex workflows, at it simplest tap works like a supercharged rake.  Using the rap executable, you can declare tasks using a syntax almost identical to rake, but with added support for configurations and documentation.  
+Tap is a framework for creating configurable, distributable tasks and workflows.
+Although scalable for complex workflows, at it simplest tap works like a
+supercharged rake.  Using the rap executable, you can declare tasks using a
+syntax almost identical to rake, but with added support for configurations and
+documentation.
+
+Note: this tutorial spans several modules in the {Tap-Suite}[http://tap.rubyforge.org/tap-suite].
+Be sure to install both tap and rap (or the full suite) beforehand.
+
+  % gem install tap-suite
 
 == Quickstart
 
-If you've used rake, tap will be easy to pick up.  To get started, make a Tapfile with a simple task declaration:
+If you've used rake, tap will be easy to pick up.  To get started, make a
+Rapfile with a simple task declaration:
 
-  [Tapfile]
+  [Rapfile]
     
   # ::desc your basic goodnight moon task
   # Says goodnight with a configurable message.
-  Tap.task(:goodnight, :obj, :message => 'goodnight') do |task, args|
+  Rap.task(:goodnight, :obj, :message => 'goodnight') do |task, args|
     puts "#{task.message} #{args.obj}\n"
   end
   
@@ -37,15 +47,18 @@ Now from the command line:
           --name NAME                  Specify a name
           --use FILE                   Loads inputs from file
   
-Just like that you have a command-line application with inputs, configuration, and documentation.  
+Just like that you have a command-line application with inputs, configuration,
+and documentation.  
 
-The declaration syntax is obviously similar to rake; configurations are new but the task-block style is the same, as are inputs.  Other rake constructs are available.  Here is a similar goodnight task using dependencies, rake-style.
+The declaration syntax is obviously similar to rake; configurations are new but
+the task-block style is the same, as are inputs.  Other rake constructs are
+available.  Here is a similar goodnight task using dependencies, rake-style.
 
-  [Tapfile]
+  [Rapfile]
   
   # make the declarations available everywhere
   # (normally they're accessed via Tap, as above)
-  include Tap::Declarations
+  include Rap::Declarations
   
   namespace :example do
     task(:say, :message) do |task, args|
@@ -53,7 +66,7 @@ The declaration syntax is obviously similar to rake; configurations are new but
     end
     
     desc "your basic goodnight moon task"
-    task({:goodnight => :say}, :obj) do |task, args|
+    task({:goodnight => 'example:say'}, :obj) do |task, args|
       puts " #{args.obj}\n"
     end
   end
@@ -66,21 +79,30 @@ And now from the command line:
   % rap goodnight world --* say hello
   hello world
 
-Unlike rake, rap inputs are written out individually and tasks are delimited by a modified double-dash.  Aside from that, you can see rap is basically a supercharged rake.  Furthermore, rap runs rake.  Directly substitute rap for rake on the command line and your tasks should run as normal (see the {Syntax Reference}[link:files/doc/Syntax%20Reference.html] for more details).
+Unlike rake, rap inputs are written out individually and tasks are delimited
+by a modified double-dash.  Aside from that, you can see rap is basically a
+supercharged rake.  Furthermore, rap runs rake.  Directly substitute rap for
+rake on the command line and your tasks should run as normal (see the Rap
+{Syntax Reference}[http://tap.rubyforge.org/rap/files/doc/Syntax%20Reference.html]
+for more details).
 
-However, supercharging rake isn't the point of Tap.  Declarations bridge the gap between rake and tap, but tap itself is a more general framework.  To get at other features like imperative workflows, testing, and distribution, we have to go beyond rap and take a look at what declarations do.
+However, supercharging rake isn't the point of Tap.  Declarations bridge the
+gap between rake and tap, but tap itself is a more general framework.  To get
+at other features like imperative workflows, testing, and distribution, we
+have to go beyond rap and take a look at what declarations do.
 
 Spoiler: declarations make subclasses of Tap::Task. 
 
 == Beyond Rap
 
-Going back to the first example, lets take a look at how a task declaration maps to a class definition:
+Going back to the first example, lets take a look at how a task declaration
+maps to a class definition:
 
-  [Tapfile]
+  [Rapfile]
   
   # ::desc your basic goodnight moon task
   # Says goodnight with a configurable message.
-  Tap.task(:goodnight, :obj, :message => 'goodnight') do
+  Rap.task(:goodnight, :obj, :message => 'goodnight') do
     puts "#{task.message} #{args.obj}\n"
   end
   
@@ -96,10 +118,11 @@ Here is a corresponding class:
     end
   end
 
-Simple enough; the name corresponds to the class, configurations (and dependencies, although they aren't show) are written out individually, and the block corresponds to process.  There are a few differences, especially relating to process, but for the moment lets gloss over them and see how Goodnight works.
+Simple enough; the name corresponds to the class, configurations (and
+dependencies, although they aren't show) are written out individually, and the
+block corresponds to process.  There are a few differences, especially relating
+to process, but for the moment lets gloss over them and see how Goodnight works.
 
-  Goodnight.configurations.to_hash         # => {:message => 'goodnight'}
-  
   goodnight = Goodnight.new
   goodnight.message                        # => 'goodnight'
   goodnight.process('moon')                # => 'goodnight moon'
@@ -108,7 +131,14 @@ Simple enough; the name corresponds to the class, configurations (and dependenci
   hello.message                            # => 'hello'
   hello.process('world')                   # => 'hello world'
 
-Totally straightforward.  Goodnight stores the default configurations, each instance has accessors to the configurations, and the defaults may be overridden during initialization, or later.  Class definitions allow validation/transformation blocks to be specified for configurations.  These blocks process inputs (ex the string inputs from the command line), quite literally defining the writer for a configuration accessor.  A set of standard blocks are available through +c+, an alias for the Tap::Support::Validation module.
+Totally straightforward.  Goodnight stores the default configurations, each
+instance has accessors to the configurations, and the defaults may be overridden
+during initialization, or later.  Class definitions allow validation/transformation
+blocks to be specified for configurations.  These blocks process inputs (ex the
+string inputs from the command line), quite literally defining the writer for a
+configuration accessor.  A set of standard blocks are available through +c+, an
+alias for the {Configurable::Validation}[http://tap.rubyforge.org/configurable/classes/Configurable/Validation.html]
+module.
 
   [lib/goodnight.rb]
   
@@ -166,9 +196,15 @@ Now from the command line:
           --name NAME                  Specify a name
           --use FILE                   Loads inputs from file
 
-Take a quick look at the documentation.  Class definitions can also map documentation and, in some cases, metadata to the command line; the configurations now have comments and reverse is a switch!  Rich mapping allows tasks to act as an script interface, not unlike {OptionParser}[http://www.ruby-doc.org/stdlib/libdoc/optparse/rdoc/classes/OptionParser.html] (surprise, tap uses OptionParser).
+Take a quick look at the documentation.  Class definitions map documentation
+and, in some cases, metadata to the command line; the configurations now have
+comments and reverse is a switch!  Rich mapping allows tasks to act as an
+script interface, not unlike {OptionParser}[http://www.ruby-doc.org/stdlib/libdoc/optparse/rdoc/classes/OptionParser.html]
+(check out the {Configurable}[http://tap.rubyforge.org/configurable/] gem and
+specifically {ConfigParser}[http://tap.rubyforge.org/configurable/classes/ConfigParser.html]
+for more details).
 
-For example this is a stand-alone goodnight script:
+This is a stand-alone goodnight script:
 
   [goodnight]
   
@@ -198,17 +234,23 @@ Now, from the command line:
   % ./goodnight --help
   ...
   
-As simple as it is to take a task to the command line, it's nice to note that tasks may be subclassed, tested, and distributed as usual.  No magic, just convenience.
+As simple as it is to take a task to the command line, it's nice to note that
+tasks may be subclassed, tested, and distributed as usual.  No magic, just
+convenience.
 
 == Tap
 
-Tap comes with two executables, rap and tap.  The tap executable is more verbose than rap for running tasks, but it is more configurable, scalable, and logically pure.  Tap comes with a number of {commands}[link:files/doc/Command%20Reference.html] but we'll focus on generate to make, test, and package a task library.  Begin by creating a tap directory structure and a task:
+Tap comes with two executables, rap and tap.  The tap executable is more
+verbose than rap for running tasks, but it is more configurable, scalable, and
+logically pure.  Tap comes with a number of {commands}[link:/files/doc/Command%20Reference.html]
+but we'll focus on generate to make, test, and package a task library.  Begin
+by creating a tap directory structure and a task:
 
   % tap generate root sample
   % cd sample
   % tap generate task goodnight
 
-Take a look at the task files an you find something like this:
+Take a look at the task files and you find something like this:
 
   [lib/goodnight.rb]
   
@@ -247,7 +289,7 @@ Take a look at the task files an you find something like this:
       app.run
 
       assert_equal ["goodnight moon"], app.results(task)
-      assert_audit_equal ExpAudit[[nil, "moon"], [task, "goodnight moon"]], app._results(task)[0]
+      assert_audit_equal [[nil, "moon"], [task, "goodnight moon"]], app._results(task)[0]
     end
   end
 
@@ -272,7 +314,8 @@ Ok, lets share it.  Print the current gemspec manifest:
   true  test/tap_test_helper.rb
   true  test/tap_test_suite.rb
   
-As you can see, this needs an update to include the task file.  Open up sample.gemspec and fix the manifest.
+As you can see, this needs an update to include the task file.  Open up
+sample.gemspec and fix the manifest.
 
   [sample.gemspec]
   
@@ -282,7 +325,7 @@ As you can see, this needs an update to include the task file.  Open up sample.g
     s.platform = Gem::Platform::RUBY
     s.summary = "sample"
     s.require_path = "lib"
-    s.add_dependency("tap", ">= 0.11")
+    s.add_dependency("tap")
     s.files = %W{
       lib/goodnight.rb
       tap.yml