ing 0.1.1

data/.gitignore

@@ -0,0 +1,5 @@
+scratch
+test/actions/orig
+test/actions/converted
+test/sandbox
+*.gem

data/GENERATORS.md

@@ -0,0 +1,2 @@
+TODO
+

data/LICENSE

@@ -0,0 +1,18 @@
+Copyright (c) 2012 Eric Gjertsen
+
+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 without restriction, including without limitation the
+rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+sell copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+  
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+   
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER 
+IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/OPTIONS.md

@@ -0,0 +1,2 @@
+TODO
+

data/README.md

@@ -0,0 +1,251 @@
+# Ing
+## Vanilla ruby command-line scripting.
+
+or gratuitous backronym: <b>I</b> <b>N</b>eed a <b>G</b>enerator! 
+
+Note this is a work-in-progress, not quite ready for use.
+
+The command-line syntax is similar to Thor's, and it incorporates Thor's 
+(Rails') generator methods and shell conventions like
+
+```ruby
+if yes? 'process foo files?', :yellow
+  inside('foo') { create_file '%foo_file%.rb' }
+end
+``` 
+but _unlike_ Thor or Rake, it does not define its own DSL. Your tasks correspond 
+to plain ruby classes and methods. Ing just handles routing from the command line 
+to them, and setting options. Your classes (or even Procs) do the rest.
+
+Option parsing courtesy of the venerable and excellent
+[Trollop](http://trollop.rubyforge.org/), under the hood.
+
+## Installation
+
+_Note: not yet gemified_
+
+    gem install ing
+    
+## A quick tour
+
+### The command line
+
+The ing command line is generally parsed as 
+
+    [ing command] [ing command options] [subcommand] [args] [subcommand options]
+    
+But in cases where the first argument isn't an built-in ing command or options, it's 
+simplified to
+
+    [subcommand] [args] [subcommand options]
+
+The "subcommand" is your task. To take some examples.
+
+    ing -r./path/to/some/task.rb some:task run something --verbose
+    
+  1. `ing -r` loads specified ruby files or libraries/gems; then
+  2. it dispatches to `Some::Task.new(:verbose => true).run("something")`.
+
+(Assuming you define a task `Some::Task#run`, in `/path/to/some/task.rb`.)
+
+You can -r as many libaries/files as you like. Of course, that gets pretty 
+long-winded. 
+
+By default, it requires a file `./ing.rb` if it exists (the equivalent of 
+Rakefile or Thorfile). In which case, assuming your task class is
+defined or loaded from there, the command can be simply 
+
+    ing some:task run --verbose
+
+### Built-in commands
+
+Ing has some built-in commands. These are still being implemented, but
+you can see what they are so far with `ing list`.
+
+The most significant subcommand is `generate` or `g`, which
+simplifies a common and familiar use-case (at the expense of some file-
+system conventions):
+
+    ing generate some:task --force
+
+Unlike Thor/Rails generators, these don't need to be packaged up as gems
+and preloaded into ruby. They can be either parsed as:
+
+  1. A __file__ relative to a root dir: e.g. __some/task__, or
+  2. A __subdirectory__ of the root dir, in which case it attempts to
+  preload `ing.rb` within that subdirectory: e.g. __some/task/ing.rb__
+
+The command above is then dispatched as normal to 
+`Some::Task.new(:force => true).call`  (`#call` is used if no method is
+specified). So you should put the task code within that namespace in the
+preloaded file.
+
+(By default, the generator root directory is specified by 
+`ENV['ING_GENERATORS_ROOT']` or failing that, `~/.ing/generators`.)
+
+_TODO: more examples needed_
+
+### A simple example of a plain old ruby task
+
+Let's say you want to run your project's tests with a command like `ing test`.
+The default is to run the whole suite; but if you just want unit tests you can
+say `ing test unit`. This is what it would look like (in `./ing.rb`):
+
+```ruby
+class Test
+
+  # no options passed, but you need the constructor
+  def initialize(options); end
+  
+  # `ing test`
+  def call(*args)
+    suite
+  end
+  
+  # `ing test suite`
+  def suite
+    unit; functional; acceptance
+  end
+
+  # `ing test unit`
+  def unit
+    type 'unit'
+  end
+
+  # `ing test functional`
+  def functional
+    type 'functional'
+  end
+
+  # `ing test acceptance`
+  def acceptance
+    type 'acceptance'
+  end
+    
+  def type(dir)
+    Dir["./test/#{dir}/*.rb"].each { |f| require_relative f }
+  end
+  
+end
+```
+    
+As you can see, the second arg corresponds to the method name. `call` is what
+gets called when there is no second arg.  Organizing the methods like this means
+you can also do `ing test type unit`: extra non-option arguments are passed into 
+the method as parameters.  
+
+For more worked examples of ing tasks, see the 
+[examples](ing/blob/master/examples) directory.
+
+[MORE](ing/blob/master/TASKS.md)
+
+### Option arguments
+
+Your tasks (ing subcommands) can specify what options they take by defining a 
+class method `specify_options`.  The best way to understand how this is done is 
+by example:
+
+```ruby
+class Cleanup
+
+  def self.specify_options(expect)
+    expect.opt :quiet, "Run silently"
+    expect.opt :path,  "Path to clean up", :type => :string, :default => '.'
+  end
+    
+  attr_accessor :options
+  
+  def initialize(options)
+    self.options = options
+  end
+  
+  # ...
+end
+```
+
+The syntax used in `self.specify_options` is Trollop - in fact what you are 
+doing is building a `Trollop::Parser` which then emits the parsed options into 
+your constructor. In general your constructor should just save the options to
+an instance variable like this, but in some cases you might want to do further
+processing of the passed options.
+
+[MORE](ing/blob/master/OPTIONS.md)
+
+### Generator tasks
+
+If you want to use Thor-ish generator methods, your task classes need a few more
+things added to their interface. Basically, it should look something like this.
+
+```ruby
+class MyGenerator
+
+  def self.specify_options(expect)
+    # ...
+  end
+  
+  include Ing::Files
+  
+  attr_accessor :destination_root, :source_root, :options, :shell
+  
+  # default == execution from within your project directory
+  def destination_root
+    @destination_root ||= Dir.pwd
+  end
+  
+  # default == current file is within root directory of generator files
+  def source_root
+    @source_root ||= File.expand_path(File.dirname(__FILE__))
+  end
+  
+  def initialize(options)
+    self.options = options
+  end
+  
+  # ...
+end
+```
+
+The generator methods need `:destination_root`, `:source_root`, and `:shell`.
+Also, `include Ing::Files` _after_ you specify any options (this is because
+`Ing::Files` adds several options automatically).
+
+[MORE](ing/blob/master/GENERATORS.md)
+
+## Motivation
+
+I wanted to use Thor's generator methods and shell conventions to write my own
+generators. But I didn't want to fight against Thor's hijacking of ruby classes.
+
+### Brief note about the design
+
+One of the design principles is to limit inheritance (classical and mixin), and
+most importantly to _avoid introducing new state via inheritance_. An important
+corollary of this is that the _application objects_, ie. your task classes, 
+must themselves take responsibility for their interface with the underlying
+resources they mix in or compose, instead of those resources providing the 
+interface (via so-called macro-style class methods, for instance).
+
+## Q & A
+
+### But what about task dependency resolution?
+
+That's what `require` and `||=` are for ;)
+
+Seriously, you do have `Ing.invoke Some::Task, :some_method` and `Ing.execute ...`
+for this kind of thing. Personally I think it's a code smell to put reusable
+code in things that are _also_ run from the command line. Is it application or
+library code? Controller or model? But `invoke` is there if you must, hopefully 
+with a suitably ugly syntax to dissuade you. :P
+
+### But what about security?
+
+Yes, this means any ruby library and even built-in classes can be exercised from
+the command line... but so what?
+
+1. You can't run module methods, and the objects you invoke need to have a
+hash constructor. So Kernel, Process, IO, File, etc. are pretty much ruled out.
+Most of the ruby built-in classes are ruled out in fact.
+
+2. More to the point, you're already in a shell with much more dangerous knives
+lying around. You had better trust the scripts you're working with!
+

data/TASKS.md

@@ -0,0 +1,21 @@
+### More about Tasks
+
+Incidentally, there's nothing stopping you from implementing the "Test" example 
+functionally. It could look (simplifying a little) like this:
+
+    Test = lambda {|arg| 
+      type = lambda {|*dirs|
+        dirs.each do |dir|
+          Dir["./test/#{dir}/*.rb"].each { |f| require_relative f }
+        end
+      }
+      suite = lambda { type['unit','functional','acceptance'] }
+      arg ? type[arg] : suite[]
+    }
+
+Ing can either invoke class instance methods (on things that respond to `new`), 
+or call Procs directly. The advantage of using classes is that some of the
+argument parsing is done for you (especially true of option arguments as we'll 
+see in a minute). You can use methods to basically model the command line 
+syntax. The advantage of Procs is you have more flexibility in how arguments
+are interpreted.

data/bin/ing

@@ -0,0 +1,5 @@
+#!/usr/bin/env ruby
+
+require File.expand_path('../lib/ing', File.dirname(__FILE__))
+
+Ing.run

data/examples/rspec_convert.rb

@@ -0,0 +1,102 @@
+# Usage:
+# ing rspec:convert    which is equivalent to
+# ing rspec:convert files './{test,spec}/**/*.rb' --convert-dir 'converted'
+#
+module Rspec
+
+  class Convert
+    
+    GSUBS = \
+    [ 
+      [ /^(\s*)(.+)\.should\s+be_true/          , '\1assert \2'            ],
+      [ /^(\s*)(.+)\.should\s+be_false/         , '\1refute \2'            ],
+      [ /^(\s*)(.+)\.should\s*==\s*(.+)$/       , '\1assert_equal \3, \2'  ],
+      [ /^(\s*)(.+)\.should_not\s*==\s*(.+)$/   , '\1refute_equal \3, \2'  ],
+      [ /^(\s*)(.+)\.should\s*=~\s*(.+)$/       , '\1assert_match(\3, \2)' ],
+      [ /^(\s*)(.+)\.should_not\s*=~\s*(.+)$/   , '\1refute_match(\3, \2)' ],
+      [ /^(\s*)(.+)\.should\s+be_(.+)$/         , '\1assert \2.\3?'        ],
+      [ /^(\s*)(.+)\.should_not\s+be_(.+)$/     , '\1refute \2.\3?'        ],
+      [ /expect\s+\{(.+)\}\.to\s+raise_error\s*\((.*)\)\s*\Z/m, 
+        'assert_raises(\2) {\1}'                                      ],
+      [ /\{(.+)\}\.should raise_error\s*\((.*)\)\s*\Z/m,
+        'assert_raises(\2) {\1}'                                        ],
+    # these next aren't quite right because they need to wrap the next 
+    # lines as a lambda. Thus the FIXME notes.
+      [ /\.should_receive\(([^\)]+)\)\.and_return\((.+)\)/,  
+        '.stub(\1, \2) do |s|  # FIXME'                                 ],
+      [ /.stub\!\(([\w:]+)\)\.and_return\((.+)\)/,
+        '.stub(\1, \2) do |s|  # FIXME'                                 ]
+      
+    ]
+    
+    def self.specify_options(expect)
+      expect.banner "Convert rspec 'should/not' matchers to minitest 'assert/refute'"
+      expect.text "It's not magic, you still need to hand edit your test files after running this"
+      expect.text "\nUsage:"
+      expect.text "  ing rspec:convert    # which is equivalent to"
+      expect.text "  ing rspec:convert files './{test,spec}/**/*.rb' --convert-dir 'converted'"
+      expect.text "\nOptions:"
+      expect.opt :pattern, "Directory glob pattern for test files",
+                 :type => :string, :default => './{test,spec}/**/*.rb'
+      expect.opt :convert_dir, "Subdirectory to save converted files",
+                 :type => :string, :default => 'converted'
+    end
+    
+    include Ing::Files
+    
+    attr_accessor :shell, :options, :destination_root, :source_root
+    
+    def destination_root; @destination_root ||= Dir.pwd; end
+    def source_root;      @source_root ||= File.dirname(__FILE__); end
+    
+    def input_files
+      @input_files ||= Dir[ File.expand_path(options[:pattern], source_root) ]
+    end
+    
+    def converted_files
+      input_files.map {|f|
+        File.join( File.dirname(f), options[:convert_dir], File.basename(f) )
+      }
+    end
+    
+    def conversion_map
+      input_files.zip(converted_files)
+    end
+    
+    def initialize(options)
+      self.options = options
+    end
+    
+    def call(pattern=nil)
+      options[:pattern] = pattern || options[:pattern]
+      shell.say "Processing #{input_files.length} input files: #{options[:pattern]}" if verbose?
+      conversion_map.each do |input_f, output_f|
+        new_lines = convert_lines(input_f)
+        create_file output_f, new_lines.join
+      end
+    end
+    alias :files :call
+    
+    private
+    
+    def convert_lines(fname)
+      count = 0; accum = []
+      File.open(fname) do |f|
+        f.each_line do |line|
+          new_line = GSUBS.inject(line) do |str, (rx, replace)|
+            str = str.gsub(rx, replace)
+          end
+          count += 1 if line != new_line
+          accum << new_line
+        end
+      end
+      shell.say_status(:convert, 
+                       "#{relative_to_original_destination_root(fname)}: " +
+                         "#{count} changes", 
+                       :green) if verbose?
+      accum
+    end
+        
+  end
+  
+end

data/ing.gemspec

@@ -0,0 +1,29 @@
+require File.expand_path("lib/ing/version", File.dirname(__FILE__))
+
+Gem::Specification.new do |s|
+  s.name        = "ing"
+  s.version     = Ing::VERSION
+  s.authors     = ["Eric Gjertsen"]
+  s.email       = ["ericgj72@gmail.com"]
+  s.homepage    = "https://github.com/ericgj/ing"
+  s.summary     = %q{Vanilla ruby command-line scripting}
+  s.description = %q{
+An alternative to Rake and Thor, Ing has a command-line syntax similar to 
+Thor's, and it incorporates Thor's (Rails') generator methods and shell 
+conventions. But unlike Thor or Rake, it does not define its own DSL. Your tasks
+correspond to plain ruby classes and methods. Ing just handles routing from the 
+command line to them, and setting options. Your classes (or even Procs) do the 
+rest.
+  }
+
+  s.rubyforge_project = ""
+
+  s.files         = `git ls-files`.split("\n")
+  s.test_files    = `git ls-files -- test/*`.split("\n")
+  s.require_paths = ["lib"]
+  s.executables   << 'ing'
+  
+  s.requirements << "ruby >= 1.9"
+    
+  s.add_development_dependency 'fakeweb'
+end