On May 12, 2009, at 11:51 PM, David Wright via RT wrote:
Show quoted text> I would rather that the build process was modified to be a
> 'suggests' with some sort of
> warning when Perl-Critic is not installed, "NOTICE: Perl-Critic is
> not installed, this module is
> disabled", or something to that effect.
Will do.
Show quoted text> One downside to this approach is that when one has 'use criticism'
> in their code and receives
> no warnings, one may believe 'all's well'. (when in fact in may not
> be).
>
> Maybe for that case there could be a flag of some sort, 'use
> criticism qw/brutal verbose/'.
> 'verbose' which would warn 'Perl-Critic not installed', along with
> the 'normal'/expected code
> execution.
Do you really want your users to see this warning every time they run
something in production?
Show quoted text> I realize that without Perl-Critic, criticism has no function, but
> to look at it from another
> perspective. I think the point is that one doesn't want the overhead
> (or potential 'style'
> warnings,...) in a production environment, this is a tool for
> developers. (not sys admins)
Personally, I wouldn't recommend using the criticism pragma at all.
The no-op behavior
when Perl-Critic is not installed just creates an extra degree of
freedom between your
development and production environments, which results in another
variable in the
equation when you're trying to reproduce bugs.
As you said, Perl-Critic is a development tool, so it should be run
only at development-time.
So I'd recommend using Test::Perl::Critic or
Test::Perl::Critic::Progressive instead, and
make Perl-Critic part of your unit tests. Is that an option for you?
