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?