quickl version 0.2.0 has been released !
* <*http://github.com/blambeau/quickl*>
* <https://rubygems.org/gems/quickl>
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
Just an FYI that the top url is munged and as a result isn't hyperlinked in OSX's Mail.app.
*cough*hoe*cough* 
···
On Jan 10, 2011, at 08:57 , Bernard Lambeau wrote:
quickl version 0.2.0 has been released !
* <*http://github.com/blambeau/quickl*>
* <https://rubygems.org/gems/quickl>
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
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 
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
···
2011/1/10 Bernard Lambeau <blambeau@gmail.com>: