Makes a lot of use of caller. This makes it pretty hard for somebody else to wrap your code if they want an extra layer of abstraction.

A better way of doing it is something like this:

sub import {
  my $me     = shift;
  my $opts   = ref($_[0]) ? shift : { for => scalar caller };
  my %wanted = map { $_ => 1 } @_;
  *{ $opts->{for} . "::logf" } = $me->_generate_logf($opts) if $wanted
+{logf};
  *{ $opts->{for} . "::logw" } = $me->_generate_logw($opts) if $wanted
+{logw};
  ...;
}

sub _generate_logf {
  shift;
  my $opts = shift;
  return sub {
    my $msg = shift;
    my $log = _get_logger($opts->{for}, shift);
    return unless $log->is_fatal;
    $log->fatal($msg);
    die "\n";
  }
}

...;
[download]

Exporters like Exporter::Tiny and Sub::Exporter support this kind of pattern — generating subs to export which have been specialized for whatever class is importing them — more easily than Exporter.pm. This technique will not only help avoid reliance on caller, making it easier for people to wrap your module, but will also help you further down the line when you are looking at making it more configurable.

Also, you didn't use strict or use warnings in your module. (And there's at least one part which would fail under use strict and currently could cause an issue under very contrived circumstances.)

Awesome, thanks for the advice. Finding a better way to get the callers was on my list of things to improve but I hadn't figured out a good way to accomplish this. In fact, IIRC, I think the code breaks if there are nested calls. I will definitely study this and see if I can get your suggestion incorporated.

I think I probably had Modern::Perl at some point which automatically inserts those pragmas. I must have accidentally deleted it. Thanks!

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate Priest";
$nysus = $PM . ' ' . $MCF;
Click here if you love Perl Monks

INFO(...), WARN(...), etc seem more intuitive than logw(...) and friends.

Yeah, was familiar but it wasn't easy enough and it didn't allow me to add categories to fine tune when messages could be turned on and off.

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate Priest";
$nysus = $PM . ' ' . $MCF;
Click here if you love Perl Monks

Logging has the same format especially timestamp for all components in the system.

Originating source of each line of logging can be easily determined from the line of logging.

Logged info must be designed to assist support engineers as well as developers (best achieved by separate or concatenated logging for each audience type

The difference between the line of logging and further information and/or guilty data needs to be clear from the logging syntax you choose.

and whatever else other monks might notice (it is also getting late for me).

I would also advise using a namespace that is less mistakable with the mathematical concept of log, i.e. use Logging instead of log. My first thought was that your module had something to do with logs to base 4 which I suggest is not so stupid given that logs to base 8 are important in devORops - a profession I recently accidentally adopted which might well be on the up.

upd+ ok you can get away with some diversity and nonconformity but you cannot ignore what the overall objective of logging is (support/maintenace of an application system) to the extent you seem to have done so in the narrowness of your scope.

upd+ if you do design it for more general use, you'd want to make a callable API of it and have your Perl module also call that.

I would also advise using a namespace that is less mistakable with the mathematical concept of log

The Log::* namespace is already widely in use for logging modules. I'm not aware of any modules in that namespace which deal with logarithms.

toby döt ink

I believe you, but logging would be a clearer term to differentiate from log, given that log (=logarithm) is a standard/core function. The harder question is whether the group will be willing to migrate the whole namespace ;)

One world, one people