Are you sick of trying to remember whether a particular helper is defined
in "List::Util" or "List::MoreUtils"? I sure am. Now you don't have to
remember. This module will export all of the functions that either of
those two modules defines.

This module provides a quick, convenient way of bootstrapping a user-local Perl
module library located within the user's home directory. It also constructs and
prints out for the user the list of environment variables using the syntax
appropriate for the user's current shell (as specified by the SHELL environment
variable), suitable for directly adding to one's shell configuration file.

More generally, local::lib allows for the bootstrapping and usage of a
directory containing Perl modules outside of Perl's @INC. This makes it easier
to ship an application with an app-specific copy of a Perl module, or
collection of modules. Useful in cases like when an upstream maintainer hasn't
applied a patch to a module of theirs that you need for your application.

'Log::Any' allows CPAN modules to safely and efficiently log messages,
while letting the application choose (or decline to choose) a logging
mechanism such as 'Log::Dispatch' or 'Log::Log4perl'.

'Log::Any' has a very tiny footprint and no dependencies beyond Perl 5.6,
which makes it appropriate for even small CPAN modules to use. It defaults
to 'null' logging activity, so a module can safely log without worrying
about whether the application has chosen (or will ever choose) a logging
mechanism.

The application, in turn, may choose one or more logging mechanisms via
Log::Any::Adapter.

This provides a Log::Dispatch log output system that appends logged events
to an array reference. This is probably only useful for testing the
logging of your code.

MIME::Charset provides informations about character sets used for MIME messages
on Internet.

*Module::Install* is a package for writing installers for CPAN (or
CPAN-like) distributions that are clean, simple, minimalist, act in a
strictly correct manner with the ExtUtils::MakeMaker manpage, and will run
on any Perl installation version 5.005 or newer.

The intent is to make it as easy as possible for CPAN authors (and
especially for first-time CPAN authors) to have installers that follow all
the best practices for distribution installation, but involve as much DWIM
(Do What I Mean) as possible when writing them.

Adds contextual tests that the harness can ignore.

This module scans potential modules used by perl programs, and returns a
hash reference; its keys are the module names as appears in '%INC' (e.g.
'Test/More.pm'); the values are hash references with this structure:

{
file => '/usr/local/lib/perl5/5.8.0/Test/More.pm',
key => 'Test/More.pm',
type => 'module', # or 'autoload', 'data', 'shared'
used_by => [ 'Test/Simple.pm', ... ],
uses => [ 'Test/Other.pm', ... ],
}

One function, 'scan_deps', is exported by default. Other functions such as
('scan_line', 'scan_chunk', 'add_deps', 'path_to_inc_name') are exported
upon request.

Users of *App::Packer* may also use this module as the dependency-checking
frontend, by tweaking their _p2e.pl_ like below:

use Module::ScanDeps;
...
my $packer = App::Packer->new( frontend => 'Module::ScanDeps' );
...

Please see the App::Packer::Frontend manpage for detailed explanation on
the structure returned by 'get_files'.

Moose is an extension of the Perl 5 object system.

The main goal of Moose is to make Perl 5 Object Oriented programming
easier, more consistent, and less tedious. With Moose you can think more
about what you want to do and less about the mechanics of OOP.

Additionally, Moose is built on top of the Class::MOP manpage, which is a
metaclass system for Perl 5. This means that Moose not only makes building
normal Perl 5 objects better, but it provides the power of metaclass
programming as well.

The MooseX::Aliases module will allow you to quickly alias methods in Moose. It
provides an alias parameter for has() to generate aliased accessors as well as
the standard ones. Attributes can also be initialized in the constructor via
their aliased names.

This module marries App::Cmd with MooseX::Getopt.

Use it like App::Cmd advises (especially see App::Cmd::Tutorial), swapping
App::Cmd::Command for MooseX::App::Cmd::Command.

Then you can write your moose commands as moose classes, with
MooseX::Getopt defining the options for you instead of "opt_spec"
returning a Getopt::Long::Descriptive spec.

This distribution is deprecated. The features it provides have been added to
the Moose core code as Moose::Meta::Attribute::Native. This distribution should
not be used by any new code.

While Moose attributes provide you with a way to name your accessors, readers,
writers, clearers and predicates, this library provides commonly used attribute
helper methods for specific types of data.

This is an abstract role which provides an alternate constructor for creating
objects using parameters passed in from a configuration file. The actual
implementation of reading the configuration file is left to concrete subroles.

It declares an attribute configfile and a class method new_with_config, and
requires that concrete roles derived from it implement the class method
get_config_from_file.

Attributes specified directly as arguments to new_with_config supercede those
in the configfile.

MooseX::Getopt knows about this abstract role, and will use it if available to
load attributes from the file specified by the commandline flag --configfile
during its normal new_with_options.

This class allows to wrap any "Moose::Meta::TypeConstraint" in a way that
will force coercion of the value when checking or validating a value
against it.

If you've ever wanted to be able to call an attribute any number of things
while you're passing arguments to your object constructor, Now You Can.

The primary motivator is that I have some attributes that were named
inconsistently, and I wanted to rename them without breaking backwards
compatibility with my existing API.

"MooseX::NonMoose" allows for easily subclassing non-Moose classes with
Moose, taking care of the annoying details connected with doing this, such
as setting up proper inheritance from Moose::Object and installing (and
inlining, at "make_immutable" time) a constructor that makes sure things
like "BUILD" methods are called.

LONG DESCRIPTION
GOES
HERE

Your parameterized role consists of two new things: parameter declarations
and a 'role' block.

Parameters are declared using the the /parameter manpage keyword which very
much resembles the Moose/has manpage. You can use any option that the
Moose/has manpage accepts. The default value for the 'is' option is 'ro' as
that's a very common case. Use 'is => 'bare'' if you want no accessor.
These parameters will get their values when the consuming class (or role)
uses the Moose/with manpage. A parameter object will be constructed with
these values, and passed to the 'role' block.

The 'role' block then uses the usual the Moose::Role manpage keywords to
build up a role. You can shift off the parameter object to inspect what the
consuming class provided as parameters. You use the parameters to customize
your role however you wish.

There are many possible implementations for parameterized roles (hopefully
with a consistent enough API); I believe this to be the easiest and most
flexible design. Coincidentally, Pugs originally had an eerily similar
design.

See the MooseX::Role::Parameterized::Extending manpage for some tips on how
to extend this module.

This role loads simple configfiles to set object attributes. It is based on the
abstract role MooseX::ConfigFromFile, and uses Config::Any to load your
configfile. Config::Any will in turn support any of a variety of different
config formats, detected by the file extension. See Config::Any for more
details about supported formats.

Like all MooseX::ConfigFromFile -derived configfile loaders, this module is
automatically supported by the MooseX::Getopt role as well, which allows
specifying -configfile on the commandline.

A singleton is a class that has only one instance in an application.
"MooseX::Singleton" lets you easily upgrade (or downgrade, as it were)
your Moose class to a singleton.

All you should need to do to transform your class is to change "use Moose"
to "use MooseX::Singleton". This module uses metaclass roles to do its
magic, so it should cooperate with most other "MooseX" modules.

MooseX::Storage is a serialization framework for Moose, it provides a very
flexible and highly pluggable way to serialize Moose classes to a number of
different formats and styles.