perlancar First, thank you for taking the time to reply. I am only slightly familiar with Log::ger based upon a review of loggers that I performed about a year ago when I decided to take a look around. At that time, as now, I have been using and am very comfortable with Log::Log4perl. I remember being interested in Log::ger and strongly considered it as well as Log::Dispatch at that time. At that time, I decided that there wasn't a compelling reason to pull me away from Log::Log4perl.

My goal at this point is a bit different than my previous search. Previously I was looking at loggers for my personal use. As I am now looking at log production for a module for CPAN, I have different criteria. My primary interest in Log::Any is based upon its goal of being a standard log production API agnostic of specific log consumption backends. While TIMTOWDI rules in perl, I perceive that Log::Any has somewhat become the defacto standard for this purpose though there are more reverse dependencies on CPAN for Log::Log4perl than there are for Log::Any

I will take another look at Log::ger. Thanks again for your response.

lbe

You're most welcome.

Log::ger actually has more reverse dependencies on CPAN than Log::Any now.

% lcpan rdeps Log::ger | wc -l
253

% lcpan rdeps Log::Any | wc -l
196

but all those Log::ger reverse deps are mine :-) (haven't found my first vict, er, author yet), while Log::Any is used on CPAN by a whooping 77 different authors:

% lcpan rdeps Log::ger | td select author | sort | uniq
PERLANCAR

% lcpan rdeps Log::Any | td select author | sort | uniq | wc -l
77

I was a long-time Log::Any user before getting annoyed enough to write the replacement, so to tell you in short why I ditched Log::Any: it stopped being lightweight enough to use in some of my modules. Startup time increases by 5-10ms. And if you use Log::Any in your module, suddenly you will also depend on things like IO::File, FindBin, Storable, Sys::Syslog:

% lcpan deps --phase runtime --rel requires Log::Any
+----------------+----------+---------+---------+
| module         | author   | version | is_core |
+----------------+----------+---------+---------+
| B              | SHAY     | 0       | 1       |
| Carp           | XSAWYERX | 0       | 1       |
| Data::Dumper   | XSAWYERX | 0       | 1       |
| Exporter       | TODDR    | 0       | 1       |
| Fcntl          | SHAY     | 0       | 1       |
| File::Basename | SHAY     | 0       | 1       |
| FindBin        | SHAY     | 0       | 1       |
| IO::File       | TODDR    | 0       | 1       |
| Storable       | XSAWYERX | 0       | 1       |
| Sys::Syslog    | SAPER    | 0       | 1       |
| Test::Builder  | EXODIST  | 0       | 1       |
| constant       | RJBS     | 0       | 1       |
| strict         | SHAY     | 0       | 1       |
| warnings       | SHAY     | 0       | 1       |
+----------------+----------+---------+---------+

% lcpan deps --phase runtime --rel requires Log::ger
+--------------+----------+---------+---------+
| module       | author   | version | is_core |
+--------------+----------+---------+---------+
| Data::Dumper | XSAWYERX | 0       | 1       |
| parent       | CORION   | 0       | 1       |
| strict       | SHAY     | 0       | 1       |
| vars         | SHAY     | 0       | 1       |
| warnings     | SHAY     | 0       | 1       |
+--------------+----------+---------+---------+

Granted, all those modules are core, but this shows that Log::Any was not the tiny little module you can just sneak in to your module without much thought anymore, especially if you want your module to also be tiny.

I have made Log::ger to be as light as strict or warnings so the impact of adding use Log::ger; to your module is really minimal. And this is really important to me because I want to be able to use logging pervasively in most (if not all) of my modules when necessary.

Log::ger basically has all the features of Log::Any plus more, with less impact to your module users.

As for Log::Dispatch, it has even much worse startup overhead. It will add ~100ms to your module's startup by loading a whole argument parameter framework (Specio, Params::ValidationCompiler) as well as many extras like Module::Runtime, File::Spec, Storable, Exception::Class, List::Util, so that's not acceptable for some cases. It will pull many non-core dependencies to your module.

Log::ger basically has all the features of Log::Any plus more, with less impact to your module users.

Thanks very much for this comparative analysis. I was entirely ignorant of Log::ger before this and therefore was using Log::Any effectively by default. Your post gives encouragement to try Log::ger as a lightweight replacement.

One minor off-topic nugget is that sort has a -u option which essentially replaces a vanilla sort | uniq and thereby saves you a process and could make the sort faster (dataset depending, of course).