MetaCPAN seems to be an attempt at a more open CPAN. It even has what looks to be a very nice API (link to beta docs). I'll have to give that a try. I have updated CPAN related links to the right to point to MetaCPAN instead of the older CPAN website. It may still be a little rough around the edges but it seems to work well enough for my purposes right now.

Exporter::Declare: After yammering about how much I like Sub::Exporter I discover another exporter that, until today, I had not heard of. It looks very promising and I plan on testing it out "sometime soon".

Sub::Exporter: I've started using this module when writing modules that have symbols to be exported. It is much better than the standard Exporter and its documentation has a handy comparison to other CPAN export modules. I've found it to be very easy to use and extremely powerful. It was used as the exporter for Moose for a reason. It is simply the best exporter available.

Reflex: the next generation project being worked on by Rocco Caputo (the author of POE). It seems to be an attempt to remake POE using a more Modern Perl approach (which, of course, means Moose among other things). It can work with existing POE components using a number of adaptor classes.

Perhaps you read, or skimmed, the story linked off of Slashdot about the module count for Ruby growing to eclipse the module count for Perl? First things first: it's wrong.

Second: is measuring module count useful? In some respects it is. A community with 10 modules would seem to be less active than a community with 1000 modules. But given the number of modules in each of the 'big' communities (Perl, Ruby, Python) it seems less useful as a metric. So what would be a good metric? Module quality? Module popularity? How can those be measured?

With the success of Moose I suppose it was inevitable that people would want to build 'lite' versions of it. Mouse has been around for almost as long as Moose, and now there is Moo which bills itself as 'almost two thirds of Moose' (get it?).

Love::Match::Calc. Apparently you can take two names and generate what is known as a love factor. I don't know what that is but it is self-evidently awesome.

Const::Fast: A replacement for using constant and Readonly. The code is ridiculously simple. The primary problems with the other modules? Readonly is built on top of tie() (so can be quite slow), and constant simply wraps the value in a sub call and so (among other things) you don't get interpolation for anything declared with 'use constant' since you aren't dealing with a scalar.

MooseX::POE: A Moose wrapper for POE::Session. Write POE modules using Moose. There is also a set of modules in the POEx namespace that purport to do something similar, but MooseX::POE seems to be maintained.

Parallel::Iterator: A module that provides a 'parallel map' function. It transparently utilizes multiple cores, performs IPC, and other stuff.

Path::Dispatcher: a dispatcher that can work just about anywhere. It works (roughly) analogously to the way mod_perl works when matching URIs and dispatching to URI handlers. This code can work in any context including the command line.

IPC::Run3: the successor to IPC::Open2. A simpler API with the same functionality.

Ever wondered about Perl modules that would help you build a dependency tree in a manner similar to make? A recent PerlMonks question was also curious. Only one answer (so far) but the question plus the answer have some interesting ideas.

The answer suggested cons. cons is a very old system and I had not realized it was still active...and based on the e-mail archive, it isn't. The FAQ was last updated in 2001. This would not likely be the first place I would look.

The question itself mentioned two modules that I was unaware of: Algorithm::Dependency and Decision::Depends. The former appears to be the module with the most recent update, but the OP seems to have chosen the latter to help him solve his problem.

Config::Model: A framework for creating configuration validation and editors. This is something I've wanted to write for awhile now. If I understand the goal of this module correctly it should make writing configuration systems very simple.

App::perlbrew: Manage perl installations in your $HOME. I can see where this can be very useful. Here is an introduction on its use.