Additional opinion on this issue: reporting errors is not an optional
feature. Reporting them *via a fancy mechanism* may be optional, and
verbose logging may be optional, but in the absence of the optional fancy
module there has to be a fallback that performs basic error reporting,
i.e., sending error messages to stderr.
Sending error messages to stderr also needs to be the default behaviour
when the fancy module *is* installed. I've never used Log4perl, so don't
know what its default is. But the default behaviour of App::Cpan needs
to be the basic conventional one. If, perchance, Log4perl defaults to
something else, installing the Log::Log4perl module (presumably to use
in one's own project) still doesn't indicate a desire to significantly
change App::Cpan's behaviour. (Small differences in the appearance of
the error messages based on whether Log4perl is installed would be OK,
provided that they're comprehensible and sent to stderr in either case.
A side issue: I have an automated process which pipes a command into
the CPAN shell and redirects stdout to /dev/null, and it's run into a
problem relating to Log4perl. The intent of the redirection is that
it'll suppress all of CPAN's usual chatter (which goes to stdout) but
still show any reports of actual errors (to stderr). With the current
version of CPAN, it shows the "Loading internal null logger" message
if Log4perl is not installed. Until I found this ticket I was thinking
that I would report this as a bug: that part of the chatter, of no real
significance, was going to stderr, making it impossible to get a clean
errors-only output. With the understanding from this ticket that the
message really does indicate a problem (that some later error messages
will be dropped), that complaint would not be correct in this case.
It turns out that "Loading internal null logger" is actually a genuine
error message, albeit with two problems. Firstly, it's not at all clear:
it looks like irrelevant chatter, but should say something like "will be
unable to output error messages later on", expressing the real impact
of the situation. Secondly, tying into the above point about error
output being an essential feature, the error condition of losing that
necessary capability ought to be taken more seriously: if Log4perl is
the only way to get error output then it should be a mandatory module,
with failure to load it causing App::Cpan to abort.
-zefram
