Amp Redux: Commands

[Justin Love]

Michael Edgar:

"Another point about the current 'amp_redux' repo which will
eventually
become amp-front (or something else): We're actually turning it into a
generic front-end for all command-line based Ruby apps. Not only would
it provide all ruby-based CLI apps (rubygems, heroku to name a few) a
common, elegant DSL for defining commands, but it would also
standardize
plugins for those systems. If you look at the code for most of these
systems,
they're filled with boilerplate and generally just suck.

The new command architecture now actually defines a new class for each
command instead of instantiating a new Amp::Command object, so you'll
be
able to take advantage of both inheritance and composition to
modularize
command code. We've already added an AR-like validation system to
simply
validate command line arguments.


The most important part of our command system is that they have to be
*customizable*.
A big, big part of the motivation for amp is that commands should be
dead simple to
make, like adding rake tasks, and they should be easy to combine.

One huge feature is open commands: the same syntax for creating a
command will
re-open an existing one, just like classes in Ruby. That way you can
reopen an existing
command (maybe one that ships with Amp), and change the default
setting for an option.
With Ruby syntax, and the same syntax for defining the commands in the
first place.

Existing VCS tools define all these ad-hoc INI formats to handle
customization. I can't
define a mercurial extension in the same place I add it to my
configuration. I can't tweak
a file that sits right in my project (like a Rakefile) and know it'll
reflect in my tool's behavior."


Justin:

Actually, when I first heard this, I thought commands would be
just 'plain-old-ruby-classes', e.g.

module Amp::Command::Base
class Help < Base
desc 'Shows this help'
def call(opts, args)
Base.all_commands.each do |command|
puts "#{command.name.downcase} - #{command.desc}"
end
end
end
end

We could probably structure this so it was possible to use 'super' for
partial extension of methods. One idea I got from this was that some
part of the options could be part of new/initialize, and then it could
be called multiple times on different arguments. Maybe I'm off on
some entirely divergent vision.