Improved Option Parsing, Command to Create Manifests

[russell_h]

All,

I mentioned on IRC the other day that I was running up against some
limitations of the command parser. Off the top of my head they came
down to:

1. It didn't allow us to mix '--option' style options with positional
arguments.
2. Options of the '--option' style couldn't take an argument separated
by a space, only '--key=val'
3. There was no way to accept the same option multiple times (into a
list, etc)
4. There was no way to specify a 'short form' for options (ie, '-f' vs
'--force')

I've just pushed a branch [1] that deals with these by:

1. Iterating the list of arguments, handling "options" (I've renamed
switches to options) and removing them as it goes
2. Using the next argv element as an argument for options that take a
value and didn't receive it in '--key=val' form
3. Making option declarations more expressive so we can better decide
what to do with values
4. Allowing multiple names to be specified for each option

The effect this has on the API is relatively minimal, although it does
make it a little more complex for simple cases. For example the
bundles/upload command went from this:

'switches': [['upload', 'Upload a bundle to the server after it is
created']]

To this:

'options': [
{
names: ['--upload'],
dest: 'upload',
action: 'store_true',
desc: 'Upload a bundle to the server after it is created'
}
]

If anyone is thinking "optparse", I definitely borrowed a few ideas
from there, although I left plenty behind as well.

I've also added an 'init' command (we can rename it if anyone has a
better idea) that shows off a lot of the new goodness, including the
help output of options:

Usage: cast init ENTRY_FILE

Description:
Create a simple manifest file by answering a series of questions.
Optionally
specify manifest parameters from the command line.

Required arguments:
ENTRY_FILE - The entry file of the application

Options:
--apppath <path>, -a <path>
Path to the root of the application

--name <name>, -n <name>
The name of the application.

--type <type>, -t <type>
Specify the type of the applicaton. Available types are 'nodejs'
and
'shell'

--template <file>, -t <file>
Specify files that should be rendered as templates during
deployment. Use
once for each file to be templated.

--datafile <file>, -d <file>
Specify files that may be programatically modified during
operation of
the application. These will not be replaced during upgrades

--force, -f
Replace an existing manifest file.



Anyway, let me know what you think.


[1]: http://github.com/cloudkick/cast/compare/master...better_switches

--
Russell Haering

[Kami]

I say merge it.

It's definitely more flexible then the old API (I tried to keep each
command file as short and simple as possible, but options and switches
being more flexible and powerful is worth adding a few more lines to
the command file imo).

And as far as the code goes, options where the action is 'append' were
not handled properly, but I have fixed that (the arguments_dictionary
object property was overridden each time).

Also, nice work on the init command.

On a side node, I am going to add bash completion for the command
options in the following days which is going to make it more useful.

[Russell]

On Wed, Oct 27, 2010 at 1:11 AM, Kami <ka...@k5-storitve.net> wrote:
> I say merge it.

Will do.

> It's definitely more flexible then the old API (I tried to keep each
> command file as short and simple as possible, but options and switches
> being more flexible and powerful is worth adding a few more lines to
> the command file imo).
>
> And as far as the code goes, options where the action is 'append' were
> not handled properly, but I have fixed that (the arguments_dictionary
> object property was overridden each time).

Good catch, I confused myself by naming that one variable 'key'.

> Also, nice work on the init command.
>
> On a side node, I am going to add bash completion for the command
> options in the following days which is going to make it more useful.

Awesome! I looked into that myself but saw the word "readline" and got
scared off. But that would definitely be awesome to have.

--
Russell Haering