HTTP::Lite is a stand-alone lightweight HTTP/1.1 implementation
for perl.

It is not intended as a replacement for the fully-features LWP module. Instead,
it is intended for use in situations where it is desirable to install the
minimal number of modules to achieve HTTP support, or where LWP is not a good
candidate due to CPU overhead, such as slower processors.

HTTP::Lite is also significantly faster than LWP.

HTTP::Lite is ideal for CGI (or mod_perl) programs or for bundling for
redistribution with larger packages where only HTTP GET and POST functionality
are necessary.

IO::All combines all of the best Perl IO modules into a single nifty
object oriented interface to greatly simplify your everyday Perl IO
idioms. It exports a single function called "io", which returns a new
IO::All object. And that object can do it all!

produce tied (and other) separate but combined variables

Lexical::Persistence does a few things, all related. Note that all the
behaviors listed here are the defaults. Subclasses can override nearly every
aspect of Lexical::Persistence's behavior.

Lexical::Persistence lets your code access persistent data through lexical
variables. This example prints "some value" because the value of $x perists in
the $lp object between setter() and getter().

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