NAME
   MooseX::App - Write user-friendly command line apps with even less
   suffering

SYNOPSIS
   In your base class:

     package MyApp;
     use MooseX::App qw(Color);

     option 'global_option' => (
         is            => 'rw',
         isa           => 'Bool',
         documentation => q[Enable this to do fancy stuff],
     ); # Global option

     has 'private' => (
         is              => 'rw',
     ); # not exposed

   Write multiple command classes (If you have only a single command class
   you should use MooseX::App::Simple instead)

     package MyApp::SomeCommand;
     use MooseX::App::Command; # important (also imports Moose)
     extends qw(MyApp); # optional, only if you want to use global options from base class

     # Positional parameter
     parameter 'some_parameter' => (
         is            => 'rw',
         isa           => 'Str',
         required      => 1,
         documentation => q[Some parameter that you need to supply],
     );

     option 'some_option' => (
         is            => 'rw',
         isa           => 'Int',
         required      => 1,
         documentation => q[Very important option!],
     ); # Option

     sub run {
         my ($self) = @_;
         # Do something
     }

   And then you need a simple wrapper script (called eg. myapp):

    #!/usr/bin/env perl
    use MyApp;
    MyApp->new_with_command->run;

   On the command line:

    bash$ myapp help
    usage:
        myapp <command> [long options...]
        myapp help

    global options:
        --global_option    Enable this to do fancy stuff [Flag]
        --help --usage -?  Prints this usage information. [Flag]

    available commands:
        some_command    Description of some command
        another_command Description of another command
        help            Prints this usage information

   or

    bash$ myapp some_command --help
    usage:
        myapp some_command <SOME_PARAMETER> [long options...]
        myapp help
        myapp some_command --help

    parameters:
        some_parameter     Some parameter that you need to supply [Required]

    options:
        --global_option    Enable this to do fancy stuff [Flag]
        --some_option      Very important option! [Int,Required]
        --help --usage -?  Prints this usage information. [Flag]

DESCRIPTION
   MooseX-App is a highly customisable helper to write user-friendly
   command line applications without having to worry about most of the
   annoying things usually involved. Just take any existing Moose class,
   add a single line ("use MooseX-App qw(PluginA PluginB ...);") and create
   one class for each command in an underlying namespace. Options and
   positional parameters can be defined as simple Moose accessors.

   MooseX-App will then

   *   Find, load and initialise the command classes (see
       MooseX::App::Simple for single command applications)

   *   Create automated help and documentation from modules POD as well as
       attributes metadata and type constraints

   *   Read, encode and validate the command line options and positional
       parameters entered by the user from @ARGV and %ENV (and possibly
       prompt the user for additional parameters see
       MooseX::App::Plugin::Term)

   *   Provide helpful error messages if user input cannot be validated
       (either missing or wrong attributes or Moose type constraints not
       satisfied)

   Commandline options are defined using the 'option' keyword which accepts
   the same attributes as Moose' 'has' keyword.

     option 'some_option' => (
         is            => 'rw',
         isa           => 'Str',
     );

   This is equivalent to

     has 'some_option' => (
         is            => 'rw',
         isa           => 'Str',
         traits        => ['AppOption'],   # Load extra metaclass
         cmd_type      => 'option',        # Set attribute type
     );

   Single letter options are treated as flags and may be combined with
   eachother.

   Positional parameters are defined with the 'parameter' keyword

     parameter 'some_option' => (
         is            => 'rw',
         isa           => 'Str',
     );

   This is equivalent to

     has 'some_option' => (
         is            => 'rw',
         isa           => 'Str',
         traits        => ['AppOption'],
         cmd_type      => 'parameter',
     );

   All keywords are imported by Moosex::App (in the app base class) and
   MooseX::App::Command (in the command class) or MooseX::App::Simple
   (single class application).

   Furthermore, all options and parameters can also be supplied via %ENV

     option 'some_option' => (
         is            => 'rw',
         isa           => 'Str',
         cmd_env       => 'SOME_OPTION',
     );

   Moose type constraints help MooseX::App to construct meaningful error
   messages and parse @ARGV in a meaningful way. These type constraints are
   supported

   *   ArrayRef: Specify multiple values ('--list value1 --list value2',
       also see app_permute)

   *   HashRef: Specify multiple key value pairs (--option key=value, also
       see app_permute)

   *   Enum: Display all possibilites

   *   Bool: Flags that do not require values

   *   Int, Num: Used for proper error messages

   Read the Tutorial for getting started with a simple MooseX::App command
   line application.

METHODS
 new_with_command
    my $myapp_command = MyApp->new_with_command();

   This constructor reads the command line arguments and tries to create a
   command class instance. If it fails it retuns a
   MooseX::App::Message::Envelope object holding an error message.

   You can pass a hash of default/fallback params to new_with_command

    my $obj = MyApp->new_with_command(%default);

 initialize_command_class
    my $obj = MyApp->initialize_command_class($command_name,%default);

   Helper method to instantiate the command class for the given command.

GLOBAL OPTIONS
 app_base
    app_base 'my_script'; # Defaults to $0

   Usually MooseX::App will take the name of the calling wrapper script to
   construct the program name in various help messages. This name can be
   changed via the app_base function.

 app_fuzzy
    app_fuzzy(1); # default
    OR
    app_fuzzy(0);

   Enables fuzzy matching of commands and attributes. Is turned on by
   default.

 app_strict
    app_strict(0); # default
    OR
    app_strict(1);

   If strict is enabled the program will terminate with an error message if
   superfluous/unknown positional parameters are supplied. If disabled all
   extra parameters will be copied to the extra_argv attribute.

   The command_strict config in the command classes allows one to set this
   option individually for each command in the respective command class.

 app_prefer_commandline
    app_prefer_commandline(0); # default
    or
    app_prefer_commandline(1);

   Specifies if parameters/options supplied via @ARGV,%ENV should take
   precedence over arguments passed to new_with_command.

 app_namespace
    app_namespace 'MyApp::Commands', 'YourApp::MoreCommands';
    OR
    app_namespace();

   Usually MooseX::App will take the package name of the base class as the
   namespace for commands. This namespace can be changed and you can add
   multiple extra namespaces.

   If app_namespace is called with no parameters then autoloading of
   command classes will be disabled entirely.

 app_command_name
    app_command_name {
        my ($package) = shift;
        # munge package name;
        return $command_name;
    };

   This coderef can be used to control how autoloaded package names should
   be translated to command names.

 app_command_register
    app_command_register
       do      => 'MyApp::Commands::DoSomething',
       undo    => 'MyApp::Commands::UndoSomething';

   This keyword can be used to register additional commands. Especially
   useful in conjunction with app_namespace.

 app_description
    app_description qq[Description text];

   Set the description. If not set this information will be taken from the
   Pod DESCRIPTION or OVERVIEW sections. (see command_description to set
   usage per command)

 app_usage
    app_usage qq[myapp --option ...];

   Set custom usage. If not set this will be taken from the Pod SYNOPSIS or
   USAGE section. If both sections are not available, the usage information
   will be autogenerated. (see command_usage to set usage per command)

 app_permute
    app_permute(0); # default
    OR
    app_permute(1);

   Allows to specify multiple values with one key. So instead of writing
   "--list element1 --list element2 --list element3" one might write
   "--list element1 element2 element3" for ArrayRef elements. HashRef
   elements may be expressed as <--hash key=value key2=value2>

GLOBAL ATTRIBUTES
   All MooseX::App classes will have two extra attributes

 extra_argv
   Carries all parameters from @ARGV that were not consumed (only if
   app_strict is turned off, otherwise superfluous parameters will raise an
   exception).

 help_flag
   Help flag that is set when help was requested.

ATTRIBUTE OPTIONS
   Options and parameters accept extra attributes for customisation:

   *   cmd_tags - Extra tags (as used by the help)

   *   cmd_flag - Override option/parameter name

   *   cmd_aliases - Additional option/parameter names

   *   cmd_split - Split values into ArrayRefs

   *   cmd_position - Specify option/parameter order in help

   *   cmd_env - Read options/parameters from %ENV

   *   cmd_count - Value of option equals to number of occurences in @ARGV

   Refer to MooseX::App::Meta::Role::Attribute::Option for detailed
   documentation.

METADATA
   MooseX::App will use your class metadata and POD to construct the
   commands and helpful error- or usage- messages. These bits of
   information are utilised and should be provided if possible:

   *   Package names

   *   required options for Moose attributes

   *   documentation options for Moose attributes

   *   Moose type constraints (Bool, ArrayRef, HashRef, Int, Num, and Enum)

   *   Documentation set via app_description, app_usage,
       command_short_description, command_long_description and
       command_usage

   *   POD (NAME, ABSTRACT, DESCRIPTION, USAGE, SYNOPSIS, OVERVIEW,
       COPYRIGHT, LICENSE, COPYRIGHT AND LICENSE, AUTHOR and AUTHORS
       sections)

   *   Dzil ABSTRACT tag if no POD is available yet

PLUGINS
   The behaviour of MooseX-App can be customised with plugins. To load a
   plugin just pass a list of plugin names after the "use MooseX-App"
   statement. (Attention: order sometimes matters)

    use MooseX::App qw(PluginA PluginB);

   Currently the following plugins are shipped with MooseX::App

   *   MooseX::App::Plugin::BashCompletion

       Adds a command that genereates a bash completion script for your
       application. See MooseX::App::Plugin::ZshCompletion for Z shell .

   *   MooseX::App::Plugin::Color

       Colorful output for your MooseX::App applications.

   *   MooseX::App::Plugin::Config

       Config files for MooseX::App applications.

   *   MooseX::App::Plugin::ConfigHome

       Try to find config files in users home directory.

   *   MooseX::App::Plugin::Term

       Prompt user for options and parameters that were not provided via
       options or params. Prompt offers basic editing capabilities and
       history.

   *   MooseX::App::Plugin::Typo

       Handle typos in command names and provide suggestions.

   *   MooseX::App::Plugin::Version

       Adds a command to display the version and license of your
       application.

   *   MooseX::App::Plugin::Man

       Display full manpage of application and commands.

   *   MooseX::App::Plugin::MutexGroup

       Allow for mutally exclusive options

   *   MooseX::App::Plugin::Depends

       Adds dependent options

   Refer to Writing MooseX-App Plugins for documentation on how to create
   your own plugins.

CAVEATS & KNOWN BUGS
   Startup time may be an issue - escpecially if you load many plugins. If
   you do not require the functionality of plugins and ability for fine
   grained customisation (or Moose for that matter) then you should
   probably use MooX::Options or MooX::Cmd.

   In some cases - especially when using non-standard class inheritance -
   you may end up with command classes lacking the help attribute. In this
   case you need to include the following line in your base class

    with qw(MooseX::App::Role::Common);

   When manually registering command classes (eg. via app_command_register)
   in multiple base classes with different sets of plugins (why would you
   ever want to do that?), then meta attributes may miss some attribute
   metaclasses. In this case you need to load the missing attribute traits
   explicitely:

    option 'argument' => (
       depends => 'otherargument',
       trait   => ['MooseX::App::Plugin::Depends::Meta::Attribute'], # load trait
    );

SEE ALSO
   Read the Tutorial for getting started with a simple MooseX::App command
   line application.

   For alternatives you can check out

   MooseX::App::Cmd, MooseX::Getopt, MooX::Options, MooX::Cmd and App::Cmd

SUPPORT
   Please report any bugs or feature requests to
   "[email protected]", or through the web interface at
   <http://rt.cpan.org/Public/Bug/Report.html?Queue=MooseX-App>. I will be
   notified, and then you'll automatically be notified of progress on your
   report as I make changes.

AUTHOR
       Maroš Kollár
       CPAN ID: MAROS
       maros [at] k-1.com

       http://www.k-1.com

CONTRIBUTORS
   Special thanks to all contributors.

   In no particular order: Andrew Jones, George Hartzell, Steve Nolte,
   Michael G, Thomas Klausner, Yanick Champoux, Edward Baudrez, David
   Golden, J.R. Mash, Thilo Fester, Gregor Herrmann, Sergey Romanov, Sawyer
   X, Roman F., Hunter McMillen, Maik Hentsche, Alexander Stoddard

COPYRIGHT
   MooseX::App is Copyright (c) 2012-15 Maroš Kollár.

   This library is free software and may be distributed under the same
   terms as perl itself. The full text of the licence can be found in the
   LICENCE file included with this module.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.