Test::Harness overloading of PERL5LIB

It appears Test::Harness stores its @INC in $ENV{PERL5LIB} when
running the test scripts:

% echo $PERL5LIB
/sw/lib/perl5:/sw/lib/perl5/darwin

% perl5.8.1 -e 'print "@INC\n"'
/sw/lib/perl5/5.8.1/darwin-thread-multi-2level /sw/lib/perl5/5.8.1 /sw/lib/perl5/darwin-thread-multi-2level /sw/lib/perl5 /sw/lib/perl5/darwin /System/Library/Perl/5.8.1/darwin-thread-multi-2level /System/Library/Perl/5.8.1 /Library/Perl/5.8.1/darwin-thread-multi-2level /Library/Perl/5.8.1 /Library/Perl /Network/Library/Perl/5.8.1/darwin-thread-multi-2level /Network/Library/Perl/5.8.1 /Network/Library/Perl .

% cat foo.t
use Test::More no_plan;
warn "\n";
warn "$ENV{PERL5LIB}\n";

% perl5.8.1 -MTest::Harness -e 'runtests("foo.t")'
foo...
./sw/lib/perl5/5.8.1/darwin-thread-multi-2level:/sw/lib/perl 5/5.8.1:/sw/lib/perl5/darwin-thread-multi-2level:/sw/lib/per l5:/sw/lib/perl5/darwin:/System/Library/Perl/5.8.1/darwin-th read-multi-2level:/System/Library/Perl/5.8.1:/Library/Perl/5 .8.1/darwin-thread-multi-2level:/Library/Perl/5.8.1:/Library /Perl:/Network/Library/Perl/5.8.1/darwin-thread-multi-2level :/Network/Library/Perl/5.8.1:/Network/Library/Perl:.

If the test script (or anywhere in whatever it's testing) does a
system(perl), that inner perl has the parent perl interpretter's @INC
ahead of its own. That ranges between an unrealistic test environment
and a fatal error:

% cat bar.t
use Test::More no_plan;
warn "\n";
system q{perl5.8.6 -e 'warn "@INC\n"'};
system "perl5.8.6 -MConfig -e 'exit'";

% perl5.8.1 -MTest::Harness -e 'runtests("bar.t")'
bar...
./sw/lib/perl5/5.8.1/darwin-thread-multi-2level /sw/lib/perl5/5.8.1/darwin-thread-multi-2level /sw/lib/perl5/5.8.1 /sw/lib/perl5/darwin-thread-multi-2level /sw/lib/perl5/5.8.6/darwin-thread-multi-2level /sw/lib/perl5/5.8.6 /sw/lib/perl5/darwin-thread-multi-2level /sw/lib/perl5/5.8.6/darwin-thread-multi-2level /sw/lib/perl5/5.8.1 /sw/lib/perl5 /sw/lib/perl5/darwin /System/Library/Perl/5.8.1/darwin-thread-multi-2level /System/Library/Perl/5.8.1/darwin-thread-multi-2level /System/Library/Perl/5.8.1 /Library/Perl/5.8.1/darwin-thread-multi-2level /Library/Perl/5.8.1/darwin-thread-multi-2level /Library/Perl/5.8.1 /Library/Perl/5.8.1 /Library/Perl /Network/Library/Perl/5.8.1/darwin-thread-multi-2level /Network/Library/Perl/5.8.1 /Network/Library/Perl . /sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level /sw/lib/perl5-core/5.8.6 /sw/lib/perl5/site_perl/5.8.6/darwin-thread-multi-2level /sw/lib/perl5/site_perl/5.8.6 /sw/lib/perl5/site_perl/5.8.6/darwin-thread-multi-2level /sw/lib/perl5/site_perl .
Perl lib version (5.8.1) doesn't match executable version (5.8.6) at /System/Library/Perl/5.8.1/darwin-thread-multi-2level/Config .pm line 33.
Compilation failed in require.
BEGIN failed--compilation aborted.

I see the same effect with Test::Harness as supplied with perl5.8.1 or
perl5.8.6 (i.e., can swap the outer and inner perl versions).

dan

--
Daniel Macks
dmacks@netspace.org
http://www.netspace.org/~dmacks

Re: Test::Harness overloading of PERL5LIB

Daniel E. Macks wrote:
> It appears Test::Harness stores its @INC in $ENV{PERL5LIB} when
> running the test scripts:
>
> % echo $PERL5LIB
> /sw/lib/perl5:/sw/lib/perl5/darwin
>
> % perl5.8.1 -e 'print "@INC\n"'
> /sw/lib/perl5/5.8.1/darwin-thread-multi-2level /sw/lib/perl5/5.8.1 /sw/lib/perl5/darwin-thread-multi-2level /sw/lib/perl5 /sw/lib/perl5/darwin /System/Library/Perl/5.8.1/darwin-thread-multi-2level /System/Library/Perl/5.8.1 /Library/Perl/5.8.1/darwin-thread-multi-2level /Library/Perl/5.8.1 /Library/Perl /Network/Library/Perl/5.8.1/darwin-thread-multi-2level /Network/Library/Perl/5.8.1 /Network/Library/Perl .
>
> % cat foo.t
> use Test::More no_plan;
> warn "\n";
> warn "$ENV{PERL5LIB}\n";
>
> % perl5.8.1 -MTest::Harness -e 'runtests("foo.t")'
> foo...
> ./sw/lib/perl5/5.8.1/darwin-thread-multi-2level:/sw/lib/perl 5/5.8.1:/sw/lib/perl5/darwin-thread-multi-2level:/sw/lib/per l5:/sw/lib/perl5/darwin:/System/Library/Perl/5.8.1/darwin-th read-multi-2level:/System/Library/Perl/5.8.1:/Library/Perl/5 .8.1/darwin-thread-multi-2level:/Library/Perl/5.8.1:/Library /Perl:/Network/Library/Perl/5.8.1/darwin-thread-multi-2level :/Network/Library/Perl/5.8.1:/Network/Library/Perl:.
>
> If the test script (or anywhere in whatever it's testing) does a
> system(perl), that inner perl has the parent perl interpretter's @INC
> ahead of its own. That ranges between an unrealistic test environment
> and a fatal error:
>
> % cat bar.t
> use Test::More no_plan;
> warn "\n";
> system q{perl5.8.6 -e 'warn "@INC\n"'};
> system "perl5.8.6 -MConfig -e 'exit'";
>
> % perl5.8.1 -MTest::Harness -e 'runtests("bar.t")'
> bar...
> ./sw/lib/perl5/5.8.1/darwin-thread-multi-2level /sw/lib/perl5/5.8.1/darwin-thread-multi-2level /sw/lib/perl5/5.8.1 /sw/lib/perl5/darwin-thread-multi-2level /sw/lib/perl5/5.8.6/darwin-thread-multi-2level /sw/lib/perl5/5.8.6 /sw/lib/perl5/darwin-thread-multi-2level /sw/lib/perl5/5.8.6/darwin-thread-multi-2level /sw/lib/perl5/5.8.1 /sw/lib/perl5 /sw/lib/perl5/darwin /System/Library/Perl/5.8.1/darwin-thread-multi-2level /System/Library/Perl/5.8.1/darwin-thread-multi-2level /System/Library/Perl/5.8.1 /Library/Perl/5.8.1/darwin-thread-multi-2level /Library/Perl/5.8.1/darwin-thread-multi-2level /Library/Perl/5.8.1 /Library/Perl/5.8.1 /Library/Perl /Network/Library/Perl/5.8.1/darwin-thread-multi-2level /Network/Library/Perl/5.8.1 /Network/Library/Perl . /sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level /sw/lib/perl5-core/5.8.6 /sw/lib/perl5/site_perl/5.8.6/darwin-thread-multi-2level /sw/lib/perl5/site_perl/5.8.6 /sw/lib/perl5/site_perl/5.8.6/darwin-thread-multi-2level /sw/lib/p
erl5/site_perl .
> Perl lib version (5.8.1) doesn't match executable version (5.8.6) at /System/Library/Perl/5.8.1/darwin-thread-multi-2level/Config .pm line 33.
> Compilation failed in require.
> BEGIN failed--compilation aborted.
>
> I see the same effect with Test::Harness as supplied with perl5.8.1 or
> perl5.8.6 (i.e., can swap the outer and inner perl versions).
>
> dan
>

Yes, it does appear that that is what's happening. And I believe it
wouldn't make any difference if there weren't two (or three!) different
versions of Perl involved - two from Fink and (maybe!) one that came
with Panther (if that's what the /System/Library stuff represents). It
seems reasonable to me that this is a situation the authors of
Test::Harness didn't anticipate.

The thing that comes readily to mind is to write a shell script that
resets PERL5LIB to where you want it and then runs Perl. Read the man
page for your favorite shell about passing parameters in. Then have your
top-level Perl run the shell script.

If this isn't helpful, please supply more information. I assumed Fink
based on the /sw/lib..., and Fink implies Mac OS (which /System/Library
seems to confirm), but /System/Library/Perl/5.8.1 implies Mac OS 10.3
(i.e. Panther). But I could be way out of line.

Just for my curiosity - why in the _WORLD_ would you want to do such a
thing? It makes my head hurt just thinking about it.

Tom Wyant

Re: Test::Harness overloading of PERL5LIB

harryfmudd [AT] comcast [DOT] net <> said:
> Daniel E. Macks wrote:
>> It appears Test::Harness stores its @INC in $ENV{PERL5LIB} when
>> running the test scripts:
[snip evidence]
> Yes, it does appear that that is what's happening. And I believe it
> wouldn't make any difference if there weren't two (or three!) different
> versions of Perl involved - two from Fink and (maybe!) one that came
> with Panther (if that's what the /System/Library stuff represents). It
> seems reasonable to me that this is a situation the authors of
> Test::Harness didn't anticipate.
>
> The thing that comes readily to mind is to write a shell script that
> resets PERL5LIB to where you want it and then runs Perl. Read the man
> page for your favorite shell about passing parameters in. Then have your
> top-level Perl run the shell script.

I don't know a reliable and general way to pass that wrapper script
into an arbitrary user of Test::Harness unless it were to replace the
perl interpretter file itself (/usr/bin/perl5.8.1 a wrapper around
/usr/bin/perl5.8.1-real). That's too fundamental a change to make IMO,
and requires perpetually remembering about it when upgrading perl.
It's also a non-trivial wrapper to write because it has to reimplement
the whole @INC determination algorithm, which uses lots of data that
is only really known by that perl interp itself. Either it's a
catch-22 (determined on-the-fly) or very fragile (hard-coded when
wrapper is created, breaks when perl is upgraded or rebuilt with
different options).

OTOH, that was the solution we used for the specific case at hand...

> If this isn't helpful, please supply more information. I assumed Fink
> based on the /sw/lib..., and Fink implies Mac OS (which /System/Library
> seems to confirm), but /System/Library/Perl/5.8.1 implies Mac OS 10.3
> (i.e. Panther). But I could be way out of line.

Correct assumptions about my perl suppliers. The reverse case was done
on OS X 10.4, where Apple supplies perl5.8.6 and fink supplies 5.8.1.

> Just for my curiosity - why in the _WORLD_ would you want to do such a
> thing? It makes my head hurt just thinking about it.

Much of fink itself is written in perl, including the functions
involved in actually building packages. Packages of perl modules are
specific to a certain perl version--fink has multiple perl versions
available to complement the one Apple supplies. Fink's own test suite
tests that the package builder can figure out details about the
various specific perl versions. That means get_perl.t runs as
perl5.8.x and it runs system("perl5.8.y -V").

Since reading Config.pm is really all fink's get_perl() needs to do,
it can just nuke PERL5LIB entirely:
system("/usr/bin/env -i perl5.8.y -V")
instead of trying to reset it to "what perl5.8.y would normally see if
its parent hadn't messed with it".

dan

--
Daniel Macks
dmacks@netspace.org
http://www.netspace.org/~dmacks

Re: Test::Harness overloading of PERL5LIB

harryfmudd [AT] comcast [DOT] net <> said:
> Daniel E. Macks wrote:
>> It appears Test::Harness stores its @INC in $ENV{PERL5LIB} when
>> running the test scripts:
[proof]
>> I see the same effect with Test::Harness as supplied with perl5.8.1 or
>> perl5.8.6 (i.e., can swap the outer and inner perl versions).
>
> Yes, it does appear that that is what's happening. And I believe it
> wouldn't make any difference if there weren't two (or three!) different
> versions of Perl involved - two from Fink and (maybe!) one that came
> with Panther (if that's what the /System/Library stuff represents). It
> seems reasonable to me that this is a situation the authors of
> Test::Harness didn't anticipate.

It appears this has been fixed in newer versions Test::Harness.
Version 2.56, the latest stable on CPAN, works, and from its Changes
file:

2.43_02 Thu Nov 25 00:20:36 CST 2004
[FIXES]
* Test::Harness now removes default paths from the paths that it
sets in PERL5LIB. This fixes RT #5649. Thanks, Schwern.

So it's fixed in perl core too, starting in 5.8.7, i.e., just after
the perl versions I had tested:(

dan

--
Daniel Macks
dmacks@netspace.org
http://www.netspace.org/~dmacks

Re: Test::Harness overloading of PERL5LIB

Daniel E. Macks wrote:
> harryfmudd [AT] comcast [DOT] net <> said:
>
>>Daniel E. Macks wrote:
>>
>>>It appears Test::Harness stores its @INC in $ENV{PERL5LIB} when
>>>running the test scripts:
>
> [proof]
>
>>>I see the same effect with Test::Harness as supplied with perl5.8.1 or
>>>perl5.8.6 (i.e., can swap the outer and inner perl versions).
>>
>>Yes, it does appear that that is what's happening. And I believe it
>>wouldn't make any difference if there weren't two (or three!) different
>>versions of Perl involved - two from Fink and (maybe!) one that came
>>with Panther (if that's what the /System/Library stuff represents). It
>>seems reasonable to me that this is a situation the authors of
>>Test::Harness didn't anticipate.
>
>
> It appears this has been fixed in newer versions Test::Harness.
> Version 2.56, the latest stable on CPAN, works, and from its Changes
> file:
>
> 2.43_02 Thu Nov 25 00:20:36 CST 2004
> [FIXES]
> * Test::Harness now removes default paths from the paths that it
> sets in PERL5LIB. This fixes RT #5649. Thanks, Schwern.
>
> So it's fixed in perl core too, starting in 5.8.7, i.e., just after
> the perl versions I had tested:(
>
> dan
>

Wonderful. Does that mean we'll be seeing a Perl 5.8.8 in Fink?

Tom Wyant

Re: Test::Harness overloading of PERL5LIB

harryfmudd [AT] comcast [DOT] net <> said:
> Daniel E. Macks wrote:
>> harryfmudd [AT] comcast [DOT] net <> said:
>>
>>>Daniel E. Macks wrote:
>>>
>>>>It appears Test::Harness stores its @INC in $ENV{PERL5LIB} when
>>>>running the test scripts:
>>
>> It appears this has been fixed in newer versions Test::Harness.
>> Version 2.56, the latest stable on CPAN, works, and from its Changes
>> file:
>>
>> 2.43_02 Thu Nov 25 00:20:36 CST 2004
>> [FIXES]
>> * Test::Harness now removes default paths from the paths that it
>> sets in PERL5LIB. This fixes RT #5649. Thanks, Schwern.
>>
>> So it's fixed in perl core too, starting in 5.8.7, i.e., just after
>> the perl versions I had tested:(
>
> Wonderful. Does that mean we'll be seeing a Perl 5.8.8 in Fink?

Certainly! Will probably be a while though...we're all busy working on
the migration to the "real" 10.4 distro (gcc4 ABI for C++). OTOH, I
added a set of test-harness-pmXXX packages so even older perl versions
can get the latest version of this module.

dan

--
Daniel Macks
dmacks@netspace.org
http://www.netspace.org/~dmacks

Re: Test::Harness overloading of PERL5LIB

Daniel E. Macks wrote:
> harryfmudd [AT] comcast [DOT] net <> said:
>
>>Daniel E. Macks wrote:
>>
>>>harryfmudd [AT] comcast [DOT] net <> said:
>>>
>>>
>>>>Daniel E. Macks wrote:
>>>>
>>>>
>>>>>It appears Test::Harness stores its @INC in $ENV{PERL5LIB} when
>>>>>running the test scripts:
>>>
>>>It appears this has been fixed in newer versions Test::Harness.
>>>Version 2.56, the latest stable on CPAN, works, and from its Changes
>>>file:
>>>
>>>2.43_02 Thu Nov 25 00:20:36 CST 2004
>>> [FIXES]
>>> * Test::Harness now removes default paths from the paths that it
>>> sets in PERL5LIB. This fixes RT #5649. Thanks, Schwern.
>>>
>>>So it's fixed in perl core too, starting in 5.8.7, i.e., just after
>>>the perl versions I had tested:(
>>
>>Wonderful. Does that mean we'll be seeing a Perl 5.8.8 in Fink?
>
>
> Certainly! Will probably be a while though...we're all busy working on
> the migration to the "real" 10.4 distro (gcc4 ABI for C++). OTOH, I
> added a set of test-harness-pmXXX packages so even older perl versions
> can get the latest version of this module.
>
> dan
>

Thank you very much.

Tom Wyant

Re: Test::Harness overloading of PERL5LIB

[A complimentary Cc of this posting was sent to
Daniel E. Macks
], who wrote in article :
> It appears Test::Harness stores its @INC in $ENV{PERL5LIB} when
> running the test scripts:

Sure.

> If the test script (or anywhere in whatever it's testing) does a
> system(perl), that inner perl has the parent perl interpretter's @INC
> ahead of its own.

Yes, this is exactly the reason why PERL5LIB is modified.

> That ranges between an unrealistic test environment

This provides THE realistic test environment; the kid Perl processes
use the same libraries as the parent. Very important if you have a
certain version of Perl installed, but are testing a differently
compiled (and differently patched) uninstalled version of Perl.

> and a fatal error:

Yes, this may catch a broken test environment (e.g., wrongly set
paths) by giving a fatal error.

Before this was implemented, it was very common that test scripts were
not actually testing the version of Perl the developer thought he is
testing.

> % cat bar.t
> use Test::More no_plan;
> warn "\n";
> system q{perl5.8.6 -e 'warn "@INC\n"'};
> system "perl5.8.6 -MConfig -e 'exit'";

Indeed, if you want to explicitly start a different version of Perl,
you better change $ENV{PERL5LIB} yourselves.

> Perl lib version (5.8.1) doesn't match executable version (5.8.6) at /System/Library/Perl/5.8.1/darwin-thread-multi-2level/Config .pm line 33.
> Compilation failed in require.
> BEGIN failed--compilation aborted.

> I see the same effect with Test::Harness as supplied with perl5.8.1 or
> perl5.8.6 (i.e., can swap the outer and inner perl versions).

This safeguard was implemented a long time ago already.

Hope this helps,
Ilya

Re: Test::Harness overloading of PERL5LIB

Ilya Zakharevich said:
>], who wrote in article :
>> It appears Test::Harness stores its @INC in $ENV{PERL5LIB} when
>> running the test scripts:
>
> Sure.
>
>> If the test script (or anywhere in whatever it's testing) does a
>> system(perl), that inner perl has the parent perl interpretter's @INC
>> ahead of its own.
>
> Yes, this is exactly the reason why PERL5LIB is modified.
>
>> That ranges between an unrealistic test environment
>
> This provides THE realistic test environment; the kid Perl processes
> use the same libraries as the parent. Very important if you have a
> certain version of Perl installed, but are testing a differently
> compiled (and differently patched) uninstalled version of Perl.
>
>> and a fatal error:
>
> Yes, this may catch a broken test environment (e.g., wrongly set
> paths) by giving a fatal error.

Huh? My PERL5LIB contains no perl-versioned components.

> Before this was implemented, it was very common that test scripts were
> not actually testing the version of Perl the developer thought he is
> testing.
>
>> % cat bar.t
>> use Test::More no_plan;
>> warn "\n";
>> system q{perl5.8.6 -e 'warn "@INC\n"'};
>> system "perl5.8.6 -MConfig -e 'exit'";
>
> Indeed, if you want to explicitly start a different version of Perl,
> you better change $ENV{PERL5LIB} yourselves.

To what? How can a process look up the value of an env var from its
parent (or maybe even need grandparent?) process?

>> Perl lib version (5.8.1) doesn't match executable version (5.8.6) at /System/Library/Perl/5.8.1/darwin-thread-multi-2level/Config .pm line 33.
>> Compilation failed in require.
>> BEGIN failed--compilation aborted.
>
>> I see the same effect with Test::Harness as supplied with perl5.8.1 or
>> perl5.8.6 (i.e., can swap the outer and inner perl versions).
>
> This safeguard was implemented a long time ago already.

Well, it appears to be de-implemented not-so-long-ago. Or
something...this crash no longer happens in the latest Test::Harness.

dan

--
Daniel Macks
dmacks@netspace.org
http://www.netspace.org/~dmacks

Re: Test::Harness overloading of PERL5LIB

[A complimentary Cc of this posting was sent to
Daniel E. Macks
], who wrote in article :
> >> It appears Test::Harness stores its @INC in $ENV{PERL5LIB} when
> >> running the test scripts:
> >> That ranges between an unrealistic test environment

> > This provides THE realistic test environment; the kid Perl processes
> > use the same libraries as the parent. Very important if you have a
> > certain version of Perl installed, but are testing a differently
> > compiled (and differently patched) uninstalled version of Perl.

> >> and a fatal error:

> > Yes, this may catch a broken test environment (e.g., wrongly set
> > paths) by giving a fatal error.

> Huh? My PERL5LIB contains no perl-versioned components.

Sorry that I can't help you with your problem. Did you actually read
the whole posting?

> >> % cat bar.t
> >> use Test::More no_plan;
> >> warn "\n";
> >> system q{perl5.8.6 -e 'warn "@INC\n"'};
> >> system "perl5.8.6 -MConfig -e 'exit'";
> >
> > Indeed, if you want to explicitly start a different version of Perl,
> > you better change $ENV{PERL5LIB} yourselves.
>
> To what? How can a process look up the value of an env var from its
> parent (or maybe even need grandparent?) process?

By reading %ENV, of course.

my %e;
BEGIN {%e = %ENV}

use Test::More no_plan;
warn "\n";

# Test::More might have changed %ENV to fit the particular version of Perl
{ local %ENV = %e;
system q{perl5.8.6 -e 'warn "@INC\n"'};
system "perl5.8.6 -MConfig -e 'exit'";
}

> > This safeguard was implemented a long time ago already.
>
> Well, it appears to be de-implemented not-so-long-ago. Or
> something...this crash no longer happens in the latest Test::Harness.

So it should be put back. As I said, in many situations Test::Harness
was testing a wrong version of Perl without this change.

Hope this helps,
Ilya

Re: Test::Harness overloading of PERL5LIB

Ilya Zakharevich said:
>> >> % cat bar.t
>> >> use Test::More no_plan;
>> >> warn "\n";
>> >> system q{perl5.8.6 -e 'warn "@INC\n"'};
>> >> system "perl5.8.6 -MConfig -e 'exit'";
>> >
>> > Indeed, if you want to explicitly start a different version of Perl,
>> > you better change $ENV{PERL5LIB} yourselves.
>>
>> To what? How can a process look up the value of an env var from its
>> parent (or maybe even need grandparent?) process?
>
> By reading %ENV, of course.
>
> my %e;
> BEGIN {%e = %ENV}
>
> use Test::More no_plan;
> warn "\n";
>
> # Test::More might have changed %ENV to fit the particular version of Perl
> { local %ENV = %e;
> system q{perl5.8.6 -e 'warn "@INC\n"'};
> system "perl5.8.6 -MConfig -e 'exit'";
> }

That has no effect whatsoever...with Test::Harness 2.42, the first
system() still has the perl5.8.1 paths (i.e., the perl used to run the
tests) ahead of the perl5.8.6 ones, and the second system() still
crashes with:

Perl lib version (5.8.1) doesn't match executable version (5.8.6) at /System/Library/Perl/5.8.1/darwin-thread-multi-2level/Config .pm line 33.

That makes sense, too...your use of BEGIN seems like it would require
Test::Harness to load the .t scripts before it sets up the test
environment.

dan

--
Daniel Macks
dmacks@netspace.org
http://www.netspace.org/~dmacks