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 
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
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