Quickl 0.2.0 Released

quickl version 0.2.0 has been released !

Quickl helps you create Ruby command line apps. From simple commands to
complex delegators (ala ‘git …’), Quickl helps via the following
features:

  • Simple command creations via simple classes
  • Delegate commands via ruby namespacing and DRY conventions
  • Command help, synopsis, overview, … provided via rdoc
  • Command options via standard OptionParser
  • Robust support for error handling
  • Command testing made easy as well

Installation:

gem install quickl

Changes:

0.2.0 / 2011-01-10

  • Enhancements

    • Command#run now takes a (optional) second argument (get it at
      command
      runtime via :requester reader)
    • Renamed Delegate → Delegator (Quickl::Delegate is kept but should
      not
      be used anymore)
    • Added IOAccessError with default reaction to Exit
    • Added valid_read_file! robustness utility
    • Moved to rspec 2.4.0, modified Rakefile and tests accordingly

Hi Bernard,

cool stuff. I like how rdoc is used to give the --help output and
instance-variables for the options. The single-command really factors
out the pattern I’m always using for my command-line options.

Some quick reflections :

  • #options could return the OptionParser object, so as to allow
    #options.on directly.
  • how is the delegator -> subcommand relation made ? it’s maybe best
    if it’s explicit.
  • if a delegator has a global option like --verbose, is @verbose =
    true going to be set in the subcommand ?

Cheers,
zimbatm

On Jan 10, 2011, at 08:57 , Bernard L. wrote:

quickl version 0.2.0 has been released !

Just an FYI that the top url is munged and as a result isn’t hyperlinked
in OSX’s Mail.app.

coughhoecough :stuck_out_tongue:

2011/1/10 Bernard L. [email protected]:

Hi!

  • #options could return the OptionParser object, so as to allow

#options.on directly.

Well, I want options to be installed on a class basis while being parsed by
a command instance. This is the only hack I’ve imagined so far. I would be
interested in any alternative one could propose that fit this double
constraint. Any idea?

Yeah I get it. Still, you could store those blocks somewhere, and
apply them when on the OptionParser instance later-on. Would that do
the trick ?

  • how is the delegator → subcommand relation made ? it’s maybe best
    if it’s explicit.

The relation is made through introspection of ruby namespacing (a delegate
simple command is a class defined under a delegator namespacing). I could
indeed propose additional features to override this proposed behavior.

Yeah, that’s what I thought :slight_smile: A bit too magic for me, but it’s just a
matter of taste.

  • if a delegator has a global option like --verbose, is @verbose =
    true going to be set in the subcommand ?

Not directly. But subcommands have access to a requester object (via an
attr_reader), which is the delegator in such a configuration. You can access
delegator.verbose. I’m still investigating the question so far…

I see, makes sense to me. Maybe if you store the options-parser blocks
like I said before, you can inherit them too, not sure if that makes
sense though.

Thanks for your feedback!
B

Cheers !
zimbatm

Hi!

  • #options could return the OptionParser object, so as to allow

#options.on directly.

Well, I want options to be installed on a class basis while being parsed
by
a command instance. This is the only hack I’ve imagined so far. I
would be
interested in any alternative one could propose that fit this double
constraint. Any idea?

  • how is the delegator -> subcommand relation made ? it’s maybe best
    if it’s explicit.

The relation is made through introspection of ruby namespacing (a
delegate
simple command is a class defined under a delegator namespacing). I
could
indeed propose additional features to override this proposed behavior.

  • if a delegator has a global option like --verbose, is @verbose =
    true going to be set in the subcommand ?

Not directly. But subcommands have access to a requester object (via an
attr_reader), which is the delegator in such a configuration. You can
access
delegator.verbose. I’m still investigating the question so far…

Thanks for your feedback!
B