A side note: LWP::Simple is a wrapper around LWP::UserAgent.

Here is how I choose new modules from CPAN. This is my way, it works for me, it is full of biases, unfair, not formalized, and probably wastes some time.

I usually start with the docs. Present just the default skeleton and a synopsis of nothing more than use This::Junk::Module; and your module is out, no matter how excellent it might be. I want to see at least a few lines of code for some basic usage. I want at least some error handling. Preferably, something like "all functions die() on error, use eval BLOCK or Try::Tiny to handle errors", especially when I need to call a lot of functions.

Also, the version number should not be 0.01 or 1.00.

I look at the tests. Testing just that the module loads without errors, or even no tests at all is almost as bad as having no usable documentation. I expect that at least some of the tests are usable examples for using the module.

I look at the source code. I expect to find mostly clean indenting, comments explaining non-obvious stuff, good names for variables and functions. I expect to be able to understand at least some relevant parts of the code at first sight.

I look at the dependencies. I prefer modules that don't require half of CPAN plus 20 3rd party libs just to save three characters in a line of code that runs once every thousand years. Modules that just depend on core perl or really common modules are ranked up.

And of course, I simply try the module if it survived that filtering process. If I can't get a hello-world example running within a few minutes, I drop that module and try the next one.

Sometimes, there is not much choice. Probably the most prominent example is DBI. DBI is excellent and the de-facto standard for accessing any kind of database from Perl. Older standards are gone and replaced by compatibility layers, like Oraperl (replacing special-built perls with Oracle OCI compiled in) or Win32::DBIODBC (replacing the old Win32::ODBC).

Alexander