On Tuesday 17 February 2009, David Golden wrote:
> On Tue, Feb 17, 2009 at 9:06 AM, Chris 'BinGOs' Williams
>
> <ch...@bingosnet.co.uk> wrote:
> > In your test I see that you use '-T' switch which makes perl ignore
> > PERL5LIB, hence the blarting about can't find LWP/RobotUA.pm in @INC.
> >
> > Now, I thought CPANPLUS ( which I smoke on ) and CPAN used the same
> > mechanism during testing, so I'm going to copy this to the
> > cpan-testers-discuss mailing list for any further comments.
>
> CPAN.pm does use the same mechanism, but often, CPAN.pm based smokers
> have LWP installed already.
>
> More generally, this line in the test file will be a problem for
> anyone that uses PERL5LIB, not just smoke testers.
>
> ok(system($^X, '-wTc', File::Spec->catfile('bin', 'checklink')) == 0);
>
> For example, if I'm on a hosted platform, and I use the system perl,
> but have CPAN.pm set to install my own additions into ~/myperl/ using
> PREFIX or INSTALL_BASE, and I set PERL5LIB to that directory, then
> even if I satisfy the LWP dependency, it's installed into a directory
> that can't be found under taint mode and would fail this test.
Aha! Thanks for the insight.
> Thus, it's really a bug in the test, not the smoker.
Well, I think it could be argued either way (caveat: "smoker" is a new term to
me in this context, but I suppose I understand it correctly). See below.
> (And that's exactly why smoke testers come in handy -- testing
> distributions under a wider range of situations and assumptions than
> they were originally developed in.)
Sure.
> As a potential solution for the test file, you should look into how
> Test::Harness handles test files. In *.t files that call for taint
> mode in the shebang line ("#!/usr/bin/perl -T"), Test::Harness
> converts all the PERL5LIB entries into "-I" switches on the command
> line when the *.t file is executed. If you want to test 'checklink'
> under taint via system(), that's probably a necessary step. See the
> source for TAP::Parser::Source::Perl for the code.
Hmm. I can see how implementing this would make the test succeed, but I'm not
sure if I'm quite happy with "fixing" it this way. The checklink script
has -T in its options so it would fail at runtime after "make install" if the
user expects to be able to have something loaded from $PERL5LIB which isn't
in the default @INC, no? Having the test suite intentionally not reveal this
problem doesn't sound like the right thing to do. And if "make test" is run
in an environment that differs from the installed one (except of course for
the things required to make sure that the stuff tested is the stuff about to
be installed, not a previous version of it possibly installed) so that
despite this test failure, the script would work when installed, I tend to
think that this would be a problem in the test environment.
Getting rid of the -T both in the script and the test case would be one
solution, but I'm not quite happy with that either, especially
because "checklink" is a CGI script in addition to a command line one.
Thoughts? Did I miss something?
