use constant _PERL_LT_5_8_4 => ($] < 5.008004) ? 1 : 0;
-our $VERSION = '1.002002'; # 1.2.2
+our $VERSION = '1.004001'; # 1.4.1
sub VERSION {
for ($_[1]) {
my $extras_load_warned;
+our $Smells_Like_VCS = (-e '.git' || -e '.svn'
+ || (-e '../../dist.ini' && (-e '../../.git' || -e '../../.svn')));
+
sub import {
strict->import;
warnings->import(FATAL => 'all');
my $extra_tests = do {
if (exists $ENV{PERL_STRICTURES_EXTRA}) {
if (_PERL_LT_5_8_4 and $ENV{PERL_STRICTURES_EXTRA}) {
- die 'PERL_STRICTUTRES_EXTRA checks are not available on perls older than 5.8.4, '
+ die 'PERL_STRICTURES_EXTRA checks are not available on perls older than 5.8.4: '
. "please unset \$ENV{PERL_STRICTURES_EXTRA}\n";
}
$ENV{PERL_STRICTURES_EXTRA};
} elsif (! _PERL_LT_5_8_4) {
- !!($0 =~ /^x?t\/.*(?:load|compile|coverage|use_ok).*\.t$/
- and (-e '.git' or -e '.svn'))
+ !!((caller)[1] =~ /^(?:t|xt|lib|blib)/
+ and $Smells_Like_VCS)
}
};
if ($extra_tests) {
use strict;
use warnings FATAL => 'all';
-except when called from a file where $0 matches:
+except when called from a file which matches:
- /^x?t\/.*(?:load|compile|coverage|use_ok).*\.t$/
+ (caller)[1] =~ /^(?:t|xt|lib|blib)/
and when either '.git' or '.svn' is present in the current directory (with
-the intention of only forcing extra tests on the author side) - or when the
-PERL_STRICTURES_EXTRA environment variable is set, in which case
+the intention of only forcing extra tests on the author side) - or when '.git'
+or '.svn' is present two directories up along with 'dist.ini' (which would
+indicate we are in a 'dzil test' operation, via L<Dist::Zilla>) -
+or when the PERL_STRICTURES_EXTRA environment variable is set, in which case
use strictures 1;
as such) get caught, but not at the cost of an XS dependency and not at the
cost of blowing things up on another machine.
-Therefore, strictures turns on indirect checking only when it thinks it's
-running in a compilation (or pod coverage) test - though if this causes
+Therefore, strictures turns on additional checking, but only when it thinks
+it's running in a test file in a VCS checkout - though if this causes
undesired behaviour this can be overridden by setting the
PERL_STRICTURES_EXTRA environment variable.
This method traps the strictures->VERSION(1) call produced by a use line
with a version number on it and does the version check.
+=head1 EXTRA TESTING RATIONALE
+
+Every so often, somebody complains that they're deploying via 'git pull'
+and that they don't want strictures to enable itself in this case - and that
+setting C<PERL_STRICTURES_EXTRA> to 0 isn't acceptable (additional ways to
+disable extra testing would be welcome but the discussion never seems to get
+that far).
+
+In order to allow us to skip a couple of stages and get straight to a
+productive conversation, here's my current rationale for turning the
+extra testing on via a heuristic:
+
+The extra testing is all stuff that only ever blows up at compile time;
+this is intentional. So the oft raised concern that it's different code being
+tested is only sort of the case - none of the modules involved affect the
+final optree to my knowledge, so the author gets some additional compile
+time crashes which he/she then fixes, and the rest of the testing is
+completely valid for all environments.
+
+The point of the extra testing - especially 'no indirect' - is to catch
+mistakes that newbie users won't even realise are mistakes without
+help. For example,
+
+ foo { ... };
+
+where foo is an & prototyped sub that you forgot to import - this is
+pernicious to track down since all -seems- fine until it gets called
+and you get a crash. Worse still, you can fail to have imported it due
+to a circular require, at which point you have a load order dependent
+bug which I've seen before now -only- show up in production due to tiny
+differences between the production and the development environment. I wrote
+L<http://shadow.cat/blog/matt-s-trout/indirect-but-still-fatal/> to explain
+this particular problem before L<strictures> itself existed.
+
+As such, in my experience so far the strictures extra testing has
+-avoided- production versus development differences, not caused them.
+
+Additionally, strictures' policy is very much "try and provide as much
+protection as possible for newbies - who won't think about whether there's
+an option to turn on or not" - so having only the environment variable
+is not sufficient to achieve that (I get to explain that you need to add
+'use strict' at least once a week on freenode #perl - newbies sometimes
+completely skip steps because they don't understand that that step
+is important).
+
+I make no claims that the heuristic is perfect - it's already been evolved
+significantly over time, especially for 1.004 where we changed things to
+ensure it only fires on files in your checkout (rather than strictures-using
+modules you happened to have installed, which was just silly). However, I
+hope the above clarifies why a heuristic approach is not only necessary but
+desirable from a POV of providing new users with as much safety as possible,
+and will allow any future discussion on the subject to focus on "how do we
+minimise annoyance to people deploying from checkouts intentionally".
+
=head1 COMMUNITY AND SUPPORT
=head2 IRC channel
git clone git://git.shadowcat.co.uk/p5sagit/strictures.git
+The web interface to the repository is at:
+
+ http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=p5sagit/strictures.git
+
=head1 AUTHOR
mst - Matt S. Trout (cpan:MSTROUT) <mst@shadowcat.co.uk>
projects / p5sagit/strictures.git / blobdiff