scripting frameworks - a cursory glance

I was looking to write a script that required quite a bit of modularity and separation of generic concerns from the scripts concerns. I have found 3 such frameworks (briefly discussed below) but would be glad to hear of others

CLI::Framework

CLI::Framework seems to be the most useable of the 3. It has good docs. It comes with two working samples, one simple example and one much more complicated. The complicated example shows how to maintain state in an application and share that state between commands. One issue is that the object-oriented access to that state in the command is via $self->$slot not $self->app->$slot thus potentially creating conflicts between application slots and command slots.

App::Cmd

App::Cmd is by the prolific and well known Ricardo Signes. Like CLI::Framework, it support subcommands. It does not come with complete samples. But the nice thing is you can find Ricardo on irc.perl.org almost anytime of the day or night. Both App::Cmd and CLI::Framework delegate option processing to Getopt::Long::Descriptive.

One key difference between the two is that you manually map application command names to modules in CLI::Framework. App::Cmd automatically loads all modules under the namespace of your application module.

Why is App::Cmd not quite as good as CLI::Framework

It's scary to pick someone over Ricardo, but the lack of working examples, along with the lack of pre-packaged common commands make CLI::Framework a bit more attractive.

On the other hand, if you have a lot of commands to write and dont like updating a central dispatch table, then the decentralized control and coordination of App::Cmd might be just the ticket for you.

App::Framework

App::Framework is interesting. The one thing it seems to lack is any mechanism for commands. In other words, it aimed to make applications more scaleable, but it has no support for application command (and subcommand) dispatch. Both of the other frameworks have support for subcommands, allowing for options to be specified both for the application as well as the (sub)commands.

But only CLI::Framework provides fully working examples of it.

Comment on scripting frameworks - a cursory glance Select or Download Code

Replies are listed 'Best First'.
Re: scripting frameworks - a cursory glance by krazyk (Beadle) on Mar 18, 2010 at 14:37 UTC
I am Glad you like CLI::Framework (I'm the author). Just a couple of things worth mentioning... Those who are interested can see CLI::Framework design goals and features for a concise list of what is offered by "CLIF." This feature list is, in a nutshell, why I created CLIF instead of using another module intended to assist in building command-line applications. There are no "conflicts between application slots and command slots." Application objects and command objects can share state using the cache. Commands are aware of the cache, but they are generally unaware of the application (metacommands are an exception). This is by design to encourage decoupling commands from applications. Commands could conceivably be used and reused independently from applications. Your commands will use `$self->cmd_method()` to call a command method and usually should not directly call app methods. However, when necessary (as in some of the built-in commands), they'll do so using `$self->get_app()->app_method()`. Thus, command methods are called via command objects and if a particular command is application-aware, it has a `get_app()` accessor which returns the app object. See the definition of a Metacommand and the POD for Command::Meta. Finally, be aware that I'm still standing behind the distribution. It's still relatively young and has some rough edges that I plan to polish. I'm doing this "on the side" and primarily for myself, but if anyone is using it and has any requests or suggestions, let me know. I'd still like to make it a nice solution for everyone's needs! One additional module to add to your list: App::CLI. Maybe I'm biased, so I'll let you draw your own conclusions.	[reply] [d/l] [select]
Re^2: scripting frameworks - a cursory glance by metaperl (Curate) on Mar 24, 2010 at 15:58 UTC
There are no "conflicts between application slots and command slots." Application objects and command objects can share state using the cache. Yes, but the cache is a component of the application object. And the command object should access application object components via `$self->app->cache` not the current way `$self->cache` HTML template entanglement survey	[reply] [d/l] [select]
Re^3: scripting frameworks - a cursory glance by krazyk (Beadle) on Mar 25, 2010 at 15:52 UTC
You are mistaken. The cache object accessible by `$self->cache()` (where `$self` is the Command) is the same cache used by the application (and your suggested `$self->app->cache()` would, if it were supported, do exactly the same thing -- access the cache shared by both the Application and the Command). Once again, the cache is shared state. It is not a "component" of the Application, but rather an instance variable (a reference to the Cache object) kept in both Application and Command. It would make no sense for "application object components" to be accessed via the cache (regardless of the syntax used to access the cache). The cache stores whatever a user wants to share (like a logging or a database object), not internal CLI::Framework data. If you're reading the code, then yes, the Cache class happens to be implemented inside the Application module (mainly because the existing Cache class is trivially simple and may later be replaced by a more powerful caching system like CHI; I decided it is unworthy of its own module at this stage). But that doesn't make it a "component" of the Application class.	[reply] [d/l] [select]
Re^4: scripting frameworks - a cursory glance by metaperl (Curate) on Mar 26, 2010 at 08:05 UTC
Re^5: scripting frameworks - a cursory glance by krazyk (Beadle) on Mar 26, 2010 at 16:43 UTC
Re^4: scripting frameworks - a cursory glance by metaperl (Curate) on Mar 25, 2010 at 19:51 UTC
Re: scripting frameworks - a cursory glance by TGI (Parson) on Mar 22, 2010 at 21:08 UTC
Badger is an application toolkit by Andy Wardley. I haven't played with it yet, but it looks pretty interesting. TGI says moo	[reply]
Re: scripting frameworks - a cursory glance by Anonymous Monk on Mar 18, 2010 at 04:59 UTC
App::DPath App::TimeTracker App::Booklist App::CPAN::Fresh	[reply]
Re^2: scripting frameworks - a cursory glance by metaperl (Curate) on Mar 18, 2010 at 15:17 UTC
What anonymous monk is saying is that there are plenty of example of App::Cmd and App::Cmd::Simple on CPAN. I looked through all of the above and didnt see any with subcommand processing. HTML template entanglement survey	[reply]
Re^3: scripting frameworks - a cursory glance by Anonymous Monk on Mar 19, 2010 at 13:57 UTC
Actually App::Cmd::Tutorial does reference subcommands. Quoting: When a new application instance is created, it loads all of the command classes it can find, looking for modules under the Command namespace under its own name. In the above snippet, for example, YourApp will look for any module with a name starting with YourApp::Command::.	[reply]
the App::Cmd advantage is moose leverage by metaperl (Curate) on Mar 23, 2010 at 17:37 UTC
MooseX::App::Cmd is a powerful leveraging of MooseX::Getopt and App::Cmd but be aware of a doc bug and the fact that it apparently does not support dispatch to subcommands. HTML template entanglement survey	[reply]
more cli frameworks... by metaperl (Curate) on Mar 24, 2010 at 20:19 UTC
I probably should type "CLI" into CPAN for a larger overview next time: CLI::Application as well as CLI::Dispatch HTML template entanglement survey	[reply]


more useful options
	PerlMonks