Skip Menu |

This queue is for tickets about the lib-with-preamble CPAN distribution.

Report information
The Basics
Id: 83498
Status: rejected
Priority: 0/
Queue: lib-with-preamble

People
Owner: Nobody in particular
Requestors: belden.lyman@gmail.com (no email address)
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 0.001000
Fixed in: (no value)



Subject: @INC hook is not locked in place
lib::with::preamble places a code hook at the beginning of @INC, and then relies upon that hook remaining at $INC[0]. In a suitably complicated codebase, there is likely to be one module which modifies the head of @INC, and some subsequent module which violates the constraints that lib::with::preamble is intended to enforce. Included in the patch is a test illustrating this failure, and a fix. I've also put this patch at https://gist.github.com/belden/5001086 - I wanted to submit this directly to your git server as a pull request but didn't succeed in figuring that out.
Subject: sticky-inc.patch
diff --git a/Makefile.PL b/Makefile.PL index cfc4d6d..8e90634 100644 --- Makefile.PL +++ Makefile.PL @@ -8,5 +8,8 @@ WriteMakefile( NAME => 'lib-with-preamble', VERSION_FROM => 'lib/lib/with/preamble.pm', PM_FILTER => 'perl my/filter', - PREREQ_PM => { 'PerlIO::via::dynamic' => 0.02 }, + PREREQ_PM => { + 'PerlIO::via::dynamic' => 0.02, + 'Array::Sticky' => 0.01, + }, ); diff --git a/lib/lib/with/preamble.pm b/lib/lib/with/preamble.pm index a6ad586..744c540 100644 --- lib/lib/with/preamble.pm +++ lib/lib/with/preamble.pm @@ -4,6 +4,7 @@ use strict; use warnings FATAL => 'all'; use File::Spec; use PerlIO::via::dynamic; +use Array::Sticky::INC; our $VERSION = '0.001000'; # 0.1.0 @@ -31,6 +32,7 @@ sub import { my ($class, $preamble, @libs) = @_; return unless defined($preamble) and @libs; unshift @INC, [ \&require_with_preamble, $preamble, @libs ]; + Array::Sticky::INC->make_sticky; } 1; diff --git a/t/lib/has_strict_violation.pm b/t/lib/has_strict_violation.pm new file mode 100644 index 0000000..68547d4 --- /dev/null +++ t/lib/has_strict_violation.pm @@ -0,0 +1,5 @@ +package has_strict_violation; + +$y = 10; + +1; diff --git a/t/lib/is_okay.pm b/t/lib/is_okay.pm new file mode 100644 index 0000000..e272ccf --- /dev/null +++ t/lib/is_okay.pm @@ -0,0 +1,6 @@ +package is_okay; + +use screws_up_INC; +use has_strict_violation; + +1; diff --git a/t/lib/screws_up_INC.pm b/t/lib/screws_up_INC.pm new file mode 100644 index 0000000..26b34eb --- /dev/null +++ t/lib/screws_up_INC.pm @@ -0,0 +1,5 @@ +package screws_up_INC; + +sub import { shift @INC } + +1; diff --git a/t/sticky-inc-hooks.t b/t/sticky-inc-hooks.t new file mode 100644 index 0000000..ab57186 --- /dev/null +++ t/sticky-inc-hooks.t @@ -0,0 +1,10 @@ +#!/usr/bin/env perl + +use strict; +use warnings; +use Test::More tests => 1; + +use lib::with::preamble 'use strict;', 't/lib', './lib'; + +eval { require is_okay }; +like( $@, qr/Global symbol "\$y" requires explicit package name.*has_strict_violation\.pm line 3/, 'our @INC hook stays in place' );
On Wed Feb 20 20:03:40 2013, BELDEN wrote: Show quoted text
> lib::with::preamble places a code hook at the beginning of @INC, and then > relies upon that hook remaining at $INC[0].
Incorrect. The only reason your test fails here is that you've got lib and t/lib in @INC without the lib::with::preamble wrapping. Normally only the lib::with::preamble version would be there, it's just that for testing itself it has to do some slight contortions. There's no requirement for it to be in $INC[0] whatsoever. In normal usage with only the lib::with::preamble entry, removing that entry from @INC has exactly the same result as removing any other entry - modules are no longer loaded from that directory. As such, this is not a bug in anything except whichever module removed an @INC entry that you wanted to keep. A documentation patch explaining how to spot such a module breaking your perl setup (which is precisely what an unwanted 'shift @INC' is - breakage) would be entirely welcome, but I'm going to mark this ticket as rejected. Thanks for playing around though, I imagine it wasn't entirely obvious that the problem was outside of this dist.