in reply to Re: Log::Any with die and carp
in thread Log::Any with die and carp

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

Replies are listed 'Best First'.
Re^3: Log::Any with die and carp
by perlancar (Hermit) on Dec 20, 2018 at 10:24 UTC

    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).

        You're welcome. Thanks for sort -u. I should know that, but sort | uniq has been in my muscle memory for god knows how many years.