They're all the same, in many respects.
In my module code, I want to be as flexible as possible. I want to be as detached from implementation details as possible.
I just want to generate a log message (or a notification, or an audit entry). I don't want to care where it ends up, how it is sent, how it is filtered/categorized, who the recipient(s) is/are, what medium(s) is/are used, etc. Let whoever uses the module configure it all.
And I don't want to reinvent the wheel, I want to use an existing framework. A logging framework seems to be a sensible choice. Let's use …
Thank God for cpanminus. Now that I'm free from having to use them, allow me to rant, no, bitch about them.
1. Bad defaults. Some default values might make sense 10-15 years ago, but not so much nowadays. For example, I'd argue that "follow" should now be default. See #2.
2. Too developer-oriented. For example, I believe "notest" should be on by default. This is compounded by the fact that installing Perl modules is so damn-slow already. See #3.
3. Too slow. Startup takes around 10-30 seconds or more. Installing …
Now that there is cpanminus, I've modified the handy little module CPAN::AutoINC to prefer cpanminus over CPAN.
So now when users download and run my programs/scripts for the first time, instead of failing with the dreaded message:
Can't locate Foo/Bar.pm in @INC (@INC contains: [a dozen or more of paths....]).
BEGIN failed--compilation aborted at /some/path line 123
which users or even Perl novices ha…
This is a draft/RFC document.
Log::Any is great if you're writing modules. You only need to say:
use Log::Any qw($log);
and then you're off producing logs with:
But if you're writing scripts/applications (and thus need to "consume" or display the logs as well), it becomes a bit of a hassle. For example, if you want to display logs to the screen with ="http://search.cpan…